I want to write my first plugin, it is for monitoring deep security from Trend Micro. This product provides an API, the problem is that I need to get the information from all hosts, because I don’t know the id of the host. The query across all hosts takes about 30-60 seconds. Now the question is whether I can run the special agent with a higher interval and store the data temporarily?
Maybe I do not understand the logic of MKP yet, please correct me. I tried to determine the logic with the jenkins plugin.
Hi,
you can configure a higher host check interval for the datasource host related to the DS, or build your script with its own timing. If you do that, your agent output should contain a cache age like’ <<<mycheck:cached(1223425634653,90)>>> . The first part between the hyphen is the actual unix time and the other the cache max age. You can find some examples in the agnet code of check_mk aged.
@rijo3 schau einmal bei dir in die Datei “~/share/check_mk/agents/special/agent_aws” .
Hier kannst du dich an ein Beispiel für “cached”-Informationen orientieren. Da dies ebenfalls
ein Special-Agent ist, solltest du einiges abschauen können
Und meinst du hier, dass du nicht weißt, auf welchem Host die API erreichbar ist? Versteh das leider aus dem Kontext nicht ganz heraus.
Doch doch, die API hat für jeden host/agent von Deep Security einen Array, mit den Konfigurationen und Status. Ich könnte direkt den Status abfragen, des Host, dafür bräuchte ich aber die ID, welche DS selbstvergibt. Daher muss ich einen request auf alle Host machen (ca. 700), und somit Dauer es auch 30-60 Sekunden.
@rijo3, ah ok, sehe ich ein.
Würde aber dann hier ein Cronjob der einmal am Tag läuft und die Daten speichert nicht reichen?
Oder vergibt DS die ID ständig neu?
Weil ansonsten erzeugt du dir doch viel zu viel Auslastung und Traffic, wenn du die jedesmal abfragst.
So einmalig am Tag angefragt und abgespeichert sollte für die meisten Zwecke reichen!?
Genau, würde einen Cronjob erstellen auf dem Check_MK, der mir vielleicht Zeilen-basiert eine Liste von
“Hostname;ID” anlegt, sodass du nur noch die Datei einlesen brauchst für deine DS-ID.
Damit könntest du relativ schnell deine ID für jeden Check/p. Host auslesen.
Und alles gut dafür sind wir da.
PS: Wohl gesagt, wenn du mehr als einen Check_MK Server hast, und du via Slave-Distribution die anderen angeschlossen hast, wird der Cronjob nicht mit verteilt. D.h. du müsstest hier schauen, wie du die Datei verteilen würdest.
Somit ist meine ursprüngliche Frage beantwortet. Und wir haben nur einen Standalone das Problem ist somit nicht relevant für uns.
Ich hätte trotzdem noch eine bitte, ich fühle mich ein wenig alleine gelassen, beim Plugin schreiben. Gibt es eine Anleitung, wie die Kommunikation von check zu special agent läuft. Auch auf den Bezug mit den Parametern. Das AWS Plugin ist ein wenig zu komplex für mich.
Klar kein Thema. Sofern man einmal den Überblick hat ist es relativ leicht.
Die wichtigsten Pfade für Entwicklungen in Check_MK sind: ~/local und ~/share.
~/local ← hier kommen selbst erstelle Sachen rein
~/share → hier holt man sich Infos von den aktuellen Checks/Regeln/Agents/Bla… NIEMALS hier was ändern, sonst ist es fix weg
Im Grunde läuft alles in Check_MK über sogenannte WATO Regeln. Die findest du unter “~/share/check_mk/web/plugin/wato/”. Dort sind diese nochmals namentlich in unterschiedlichen Dateien vermerkt, wie z.B. für dich der “datasource_programs.py”. Dort findest du die Regel für “special_agents:aws” (<- hier nach suchen).
Eigene Regeln kommen somit in den “Counter”-Part zum genannten Verzeichnis, also:
“~/local/share/check_mk/web/plugins/wato/”
WICHTIG: Mit der Version 1.6 ändern sich einige Verzeichnisse, allerdings sollten diese abwärts-kompatible sein.
Ähnliches gilt für Checks, auch hierzu gibt es unter “~/share/check_mk/web/plugins/wato/” Regeln, die eventuelle Schwellwerte setzen können (oder für die Agent Bakery ).
Am besten schaust du dir die Guideline von Check_MK mal an!
Edit: Diese Doku wäre für dich nach der obrigen gedacht, für die “Datasource Programs”-Entwicklung
Einzige ausnahme hier sind “active Checks” und “local Scripts”, da die Ihre Daten selbst abfragen, bzw. den Service selbst definieren.
Theoretisch also: Ja, es ist möglich einen “Datasource Programs”-Agent zu nutzen ohne einen passenden Check zu haben. Du brauchst nur eine Regel, womit du den Agent steuerst, bzw. explizit zuweist. Nur Informationen ohne einen Check, der die ausliest und verwertet, bringt ja auch nix
Danke dir für die Erleuterung, ich wollte dies nun an einem einfachen Beispiel testen. Ich Frage einfach eine interne API ab. Spielt ja nun keine Rolle. wato brauche ich ja noch nicht, da keine Parameter setzen muss.
Ich habs nun auch noch mit einem agent_pikett check erweitert, als ich einen Fehler drin hatte, motze er, aber ohne tippfehler kommt wieder keinen Output:
Naja der Special Agent muss erstmal ordentlich einen Output bringen.
Was kommt den zur Zeit raus dabei?
Für das ganze Argument Parsing würde ich eher auf immer vorhandene Tools zurückgreifen.
Damit entweder “getopt” oder “argparse” verwenden das sollte immer da sein.
Okay ich glaube es sieht wohl gar nicht so schlecht aus.
Mit den Debug Befehlen, sieht es wohl so aus, als ob alles durch laufen würde.
Der print im agent_print (check), ausserhalb der Funktionen wird nun ausgegeben.
Jedoch nicht die info der inventory funktion
OMD[ipa_rijo3]:~/local/share/check_mk/checks$ check_mk --checks=pikett -v -I server123
blub1
Discovering services on: server123
server123:
+ FETCHING DATA
[agent] Execute data source
[piggyback] Execute data source
+ EXECUTING DISCOVERY PLUGINS (1)
SUCCESS - Found nothing new
OMD[ipa_rijo3]:~/local/share/check_mk/checks$ cmk --debug -vp --checks pikett server123
blub1
Check_MK version 1.5.0p22
+ FETCHING DATA
[agent] Execute data source
[piggyback] Execute data source
OK - [agent] Version: 1.4.0p31, OS: windows, execution time 0.2 sec | execution_time=0.218 user_time=0.010 system_time=0.000 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=0.213
Das “blub1” hat dort nix verloren. Keine Ahnung wo das herkommt.
Mach mal den Aufruf für den Test bitte mit cmk --debug -vvII server123
Damit bekommst alle Fehlermeldungen und es ist sichergestellt, dass er immer alle Services neu sucht.
Der Befehl cmk --debug -vvII server123 ergab folgendes:
Discovering services on: server123
server123:
+ FETCHING DATA
[agent] Not using cache (Don't try it)
[agent] Execute data source
[agent] Connecting via TCP to 1.1.1.1:6556 (5.0s timeout)
[agent] Reading data from agent
[agent] Write data to cache file /omd/sites/ipa_rijo3/tmp/check_mk/cache/wsstadt098.stadt.winroot.net
[agent] Using persisted section 'win_disks'
[agent] Using persisted section 'win_video'
[agent] Using persisted section 'win_system'
[agent] Using persisted section 'disk_space_total'
[agent] Using persisted section 'win_bios'
[agent] Using persisted section 'win_exefiles'
[agent] Using persisted section 'win_cpuinfo'
[agent] Using persisted section 'win_networkadapter'
[agent] Using persisted section 'win_reg_uninstall'
[agent] Using persisted section 'win_os'
[agent] Using persisted section 'win_wmi_software'
[piggyback] No persisted sections loaded
[piggyback] Execute data source
+ EXECUTING DISCOVERY PLUGINS (1590)
//Tausende Services und Pikett is darunter auch ersichtlich
In der Auflistung ist er aber nicht dabei?
Wie schaut den die Agent Ausgabe im Moment aus die vom Server kommt? Jedenfalls die Sektion für deinen Check.