My first check_mk extension for trendmicro deep security

Hello

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.

Thanks for your help in advance

Kind Regards,
Jovin

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.

Regards,
Christian

1 Like

Thanks for your response
Können Sie sonst auf Deutsch antworten?

what do you mean with: the datasource host related to the DS
where can i do that?

And is check_mk aged a plugin?, i couldn’t find it.

@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 :wink:

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.

Grüße Kruzgoth

1 Like

Herzlichen Dank ich werde mir das mal anschauen.

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!?

Ja das ist wohl die einfachste Idee. Wollte nur wissen, ob Check_MK nicht ein integriertes Mittel hat.

In demfall würdest du diesen Cronjob auf dem Check_MK Server erstellen?

Und dann sollte der Check hingehen und den Host aus dem json rauslesen und den Status returnen?

Tut mir leid, ich bin wirklich ein Neuling.

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 :slight_smile: 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.

Danke dir :blush:

Somit ist meine ursprüngliche Frage beantwortet. Und wir haben nur einen Standalone :grin: 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 :wink:

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 :slight_smile: (oder für die Agent Bakery :wink: ).

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

1 Like

Okay vielen Dank, das war eigentlich nicht meine Intension, aber die Dokumentaionen könnten da dein Wissen schon mal gut gebrauchen. :slightly_smiling_face:

Ich hab indemfall was Missverstanden, es ist möglich einen special agent alleine zu nutzen? braucht check_mk keinen check um diesen anzusteuern?

Check_MK führt dann den special agent aus, mit den parametern die man im wato definiert, z.B: User/PW und der Host welcher im Service gewählt wurde?

Ich habe versucht mit dem jenkins plugin das verständndis zu erlangen, hat mich wohl mehr verwirrt.

Check_MK steuert → Check_MK Agent und/oder Datasource Programs → Erhält Daten → schickt daten an Check.

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 :wink:

1 Like

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.

~/local/share/check_mk/agents/special/pikett:

import requests
import urllib3

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

url = "https://api.example.net/api/pikett/getstatus"

rawresponse = requests.get(url, verify=False)

response = rawresponse.json()
print '<<<pikett>>>'

print(response['return']['result']['result']['active_user'])

Special agent ist alleine ausführbar

~/local/share/check_mk/checks/pikett

def inventory_pikett(info):
    print info
    return []

def check_pikett(item, parmas, info):
    print "blub"
    return 0, "pikett vergeben"

check_info["pikett"] = {
    'check_function'        : check_pikett,
    'inventory_function'    : inventory_pikett,
    'service_description'   : 'Pikett Watcher %s',
}

Überprüfung des Checks:

check_mk --checks=pikett -I server101

Und da erhalt ich keine Antwort, wahrscheinlich ein technsiches Problem, kein Missverständnis

wenn du weiter mir so hilfst würde ich dir gerne mal ein Kaffe bezahlen :grin:

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:

~/local/share/check_mk/checks/agent_pikett

#!/usr/bin/env python
# -*- encoding: utf-8; py-indent-offset: 4 -*-

def agent_pikett_arguments(servicespecs, hostname, ipaddress):
    params = {'servicespecs': servicespecs,
              'hostname': hostname,
              'ipadress': ipaddress}

    import cPickle
    import base64
    print "arg"

    cmd += base64.encodestring(cPickle.dumps(params)).split('\n')

    return " ".join(cmd)

special_agent_info['pikett'] = agent_pikett_arguments

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.

 OMD[ipa_rijo3]:~/local/share/check_mk/agents/special$ python pikett
 <<<pikett>>>
 user123

Das ist die Ausgabe vom special agent.

Also sollte Argparse in den agent check eingebaut werden?

Sollten nicht die prints ersichtlichtlich sein? werden dies nicht ausgegen, oder werden die Files überhaupt nicht ausgeführt?

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.

Das Blub war mein print test

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

 2 df
  1 dotnet_clrmemory
  7 logwatch
  1 mem.win
  1 services.summary
  1 systemtime
  1 uptime
  2 winperf_if
  1 winperf_phydisk
  1 winperf_processor.util
  1 wmi_cpuload
SUCCESS - Found 19 services

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.