@creiss Interessant, dann probiere ich das mal aus mit 365 Tagen oder so.
Vielleicht wird das Feature Feedback ja priorisiert wenn sich mehr Leute melden die sich dies wünschen.

Geschrieben hatte ich dem Support auszugsweise folgendes:
"Momentan habe ich eingestellt dass die Logbuch Einträge archiviert werden, die älter als 90 Tage sind. Mittlerweile wird klar dass dies Einträge archiviert, die durchaus interessant/wichtig sind. Gerade wenn ein Dokumentationsfehler gefunden wird, ist interessant wer dies zB. vor 6 Monaten Eingetragen hat. Und die Wiederherstellungsfunktion scheint auch nicht für einzelne Objekte zu funktionieren

Also beispielsweise habe ich öfters gesehen dass das Logbuch von manchen Objekten nur 2-3 Einträge innerhalb der letzten 90 Tage haben, während andere Objekte ~50 oder noch viel mehr Einträge durch den JDISC-Import haben(zB. tägliche aktualisierung des lokalen Speicherstands)

Würde es hier nicht Sinn machen das Archivieren genauer einstellen zu können?
Anhand folgender Eigenschaften:

1. Von wem kam diese Änderung? (Manuelle Änderungen sind wichtiger als Änderungen durch JDISC)
2. Wie viele Änderungen sind vorhanden? (zB. immer die ältesten löschen so dass maximal 50 je Objekt enthalten sind)
3. In welcher Kategorie wurde etwas geändert? (Habe schon oft gesehen dass jeden Tag der Name des lokalen Datenträgers neu gesetzt wird, diese Info ist somit dupliziert und unnötig)."

@chrisl Moin, ich glaube du bringst da paar Sachen durcheinander.

Das SAP-System dass ihr erstellt habt ist ein Objekttyp, während Software-Assignment eine Kategorie ist.

Wenn SAP-System eine Software ist, sollte diese auch als Application-Objekt angelegt werden. (Dann erscheint diese im Software-Assignment Objekt-Browser).

Vielleicht hilft euch das ja schon

@fabilbng1
Hallo, ich weiß gerade nicht ob es da in der Dokumentation etwas zu gibt - jedoch nutzen wir bereits seit knapp 2 Jahren rückwärtige Kategorien durch Reports.

Beispiel zugeordnete WLAN Bridges an Medizingeräten.

Report:

Feld in der benutzerdefinierten Kategorie:

@lfischer Alles klar, vielen Dank! Dem habe ich nichts hinzuzufügen. Dann kann das Thema geschlossen werden

Habe die Kategorie-Einträge in den ~70 Switchen mit einem Kollegen nun doch manuell gelöscht. Search Index erneuert:

Das einzige was mich wundert, ist dass hier 300.000 Einträge sind, und vorher ~135.000. Aber vielleicht war das ja auch nur der Part bis zum Error

Die Suche scheint wieder schneller zu funktionieren. Die anderen Fragen dürfen Sie natürlich gerne trotzdem beantworten @LFischer

@lfischer Hallo, erstmal vielen Dank für die ausführliche Antwort.

Ja, das hast du richtig gesehen! Habe den Netzwerkimport gestern danach noch einmal manuell ausgeführt. Nach weiterer anpassung des memory_limit Wertes(4G) zeigte sich dieser Suchindex-Count:

Habe die Kategorie JDISC Custom-Attributes danach wieder aus dem Netzwerk-Import entfernt. Nachdem ich den Netzwerk-Import eben manuell ausgeführt habe, hat sich der Suchindex nicht verändert, so wie es sein soll.
Also 1. Problem(BUG): Beim JDISC-Import der JDISC Custom Attributes werden die 270 Datensätze bei Switchen jedes mal zusätzlich importiert, anstatt nur jeweils die neu gescannten Datensätze! (Bei mir waren nach ein paar Tagen je Switch ~1200 Einträge in der JDISC Custom Attributes Kategorie, welche Standardmäßig natürlich auch für die Suche indiziert wird.

Die Idee mit der Kategorie-Whitelist für den such-index ist sicher eine Idee Wert, aber natürlich nur Pfusch am Werk, bzw. es löst das Problem nur in vorm eines übergeklebten Tape-Klebebands. (Am Rande gesagt als Feature-Feedback wäre eine Blacklist hier in meinem Fall deutlich sinnvoller. Für das manuelle Eintragen habe ich keine Zeit - vielleicht gibts ansonsten eine Möglichkeit alle "aktiven" Kategorie-Bezeichnungen zu exportieren?)

"Dann müsste ich die Daten aus den Switchen nicht rauslöschen" - da möchte ich wiedersprechen. Es sind ja trotzdem VIEL zu viele Kategorieeinträge, (die mit der zeit veralten) - und wenn wir schon beim Thema "weniger Datenmüll" sind, ist es natürlich essentiell wichtig diese Daten wieder zu löschen.
Frage: Gibt es eine Möglichkeit alle Einträge der Kategorie JDISC Custom Attributes zu löschen? Vielleicht auf Datenbank-Ebene? (Beim search-index-Befehl wird auf die Tabelle isys_catg_jdisc_ca_list Bezug genommen)

Freue mich über weitere Hilfe/Antworten.

Vielleicht sind noch ein paar Zahlen interessant:
Kategorie : Einträge
C__CATG__NETWORK_PORT: 50.000
C__CATG__GLOBAL: 80.000
C__CATG__MODEL: 32.000
C__CATG__DRIVE: 52.000
C__CATG__JDISC_CA: 434.000
C__CATG__IDENTIFIER: 27.000

Betroffen sind circa 70 Switche, und ich würde nur ungern jeden einzeln öffnen und die Daten wieder rauslöschen. Trotzdem irgendwie komisch, dass aus 90 Revisionen der Running-Config, Startup-Config und Show-Version circa 1200 Kategorie-Einträge je Switch resultiert. Sieht fast so aus als würden diese täglich importiert werden (nicht nur die neuen)

Hier noch ein Bild aus JDISC:

@lfischer Hallo! Das waren super Tipps, ganz vielen Dank!

Also vorher:

Und nachher:

-> Beim ausführen dauerte der Punkt "JDISC Custom Attributes" Ewigkeiten. Dabei fiel mir ein, dass ich so etwas letztens einfach mal angehakt hatte im jdisc-import-Profil. Nämlich im Netzwerk-Profil:

Bei einem Beispiel-Switch sind in der Kategorie Custom Attributes 1160 Einträge mit ner Menge Text(Running Configs etc) - kein wunder dass es so langsam ist/crashed. Damit habe ich beim setzen des Hakens natürlich nicht gerechnet.

Haben Sie einen Tipp wie ich das wieder bereinigen kann? Einfach den haken entfernen wird ja wahrscheinlich nicht reichen. Kann ich da eine Tabelle leeren in sql?

Vielen Dank schonmal, nun weiß ich zumindest woran es liegt.

@chrisl Moin, ich glaube du bringst da paar Sachen durcheinander.

Das SAP-System dass ihr erstellt habt ist ein Objekttyp, während Software-Assignment eine Kategorie ist.

Wenn SAP-System eine Software ist, sollte diese auch als Application-Objekt angelegt werden. (Dann erscheint diese im Software-Assignment Objekt-Browser).

Vielleicht hilft euch das ja schon

Hallo,

in der Hoffnung dass hier jemand eine Idee hat erläutere ich mal mein Problem:
Die i-doit-jobs Datei wird täglich früh morgens per Cronjob ausgeführt - funktioniert.
Manuell hinzugefügt hatte ich den LDAP-Sync Befehl - funktioniert.

Neuerdings bemerkten wir öfters dass der LDAP-Sync nicht automatisch gelaufen ist.
Nach manuellem ausführen der i-doit-jobs Datei kam beim Befehl search-index beim Punkt "C__CATG__ADDRESS" der Fehler:

Finished reading 13 rows

Start mapping 13 rows to 117 documents for "Anschrift" (C__CATG__ADDRESS)

50 of 117 documents were skipped!

Start inserting documents

Finished inserting documents!


Start inserting documents

Finished inserting documents!

PHP Fatal error:  Allowed memory size of 2147483648 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/src/classes/components/isys_component_database_mysqli.class.php on line 275

Wie in der Fehlermeldung ggf. ersichtlich ist, habe ich durch einen Tipp des i-doit-Supports den Wert memory_limit in der Datei /etc/php/7.3/mods-available/i-doit.ini bereits von 128M auf mittlerweile 2G geändert. (https://kb.i-doit.com/pages/viewpage.action?pageId=10223831#DebianGNU/Linux-PHP).

Nach dieser Änderung konnte ich den search-index-Befehl jedes mal ohne Fehler ausführen - am nächsten Morgen kam aber wieder der gleiche Fehler. Und wenn eine Erhöhung um das 16fache nicht reicht, wirkt es auf mich nach keinem normalen Verhalten. Womöglich besteht dies seit dem 1.17.1 Update - da bin ich mir nicht ganz sicher.

Hat jemand eine Idee woran es liegen könnte, was ich prüfen könnte?
Hatte diesen Fehler vorher nie

System-Infos;
i-doit 1.17.1
Linux Debian VM

@oya-erdayı Falls es noch wichtig ist, hier geht es sicherlich um den Unterschied der Felder Objekt-Browser und Objekt-Beziehung.

@creiss Interessant, dann probiere ich das mal aus mit 365 Tagen oder so.
Vielleicht wird das Feature Feedback ja priorisiert wenn sich mehr Leute melden die sich dies wünschen.

Geschrieben hatte ich dem Support auszugsweise folgendes:
"Momentan habe ich eingestellt dass die Logbuch Einträge archiviert werden, die älter als 90 Tage sind. Mittlerweile wird klar dass dies Einträge archiviert, die durchaus interessant/wichtig sind. Gerade wenn ein Dokumentationsfehler gefunden wird, ist interessant wer dies zB. vor 6 Monaten Eingetragen hat. Und die Wiederherstellungsfunktion scheint auch nicht für einzelne Objekte zu funktionieren

Also beispielsweise habe ich öfters gesehen dass das Logbuch von manchen Objekten nur 2-3 Einträge innerhalb der letzten 90 Tage haben, während andere Objekte ~50 oder noch viel mehr Einträge durch den JDISC-Import haben(zB. tägliche aktualisierung des lokalen Speicherstands)

Würde es hier nicht Sinn machen das Archivieren genauer einstellen zu können?
Anhand folgender Eigenschaften:

1. Von wem kam diese Änderung? (Manuelle Änderungen sind wichtiger als Änderungen durch JDISC)
2. Wie viele Änderungen sind vorhanden? (zB. immer die ältesten löschen so dass maximal 50 je Objekt enthalten sind)
3. In welcher Kategorie wurde etwas geändert? (Habe schon oft gesehen dass jeden Tag der Name des lokalen Datenträgers neu gesetzt wird, diese Info ist somit dupliziert und unnötig)."