Regelmäßig wiederkehrenden Status überwachen
Zusätzlich zu dem Status, der auf der Karte eines Modell angezeigt wird, können Sie die Generierung eines periodischen Status einschalten, welcher dann über Operationen oder Ereignisse von
Cumulocity IoT veröffentlicht wird. Siehe
Konfiguration zur Einstellung der Mandantenoptionen
status_device_name und
status_period_secs.
Jede Operation hat die folgenden Parameter:
Parameter | Beschreibung |
models_running | Informationen zu den aktiven Modellen, die ausgeführt werden. |
models_failed | Informationen zu den aktiven Modellen, bei denen ein Fehler aufgetreten ist. |
chain_diagnostics | |
apama_status | Statusmetriken des Apama-Korrelators. Viele Statusnamen entsprechen den Key-Namen im REST-API von Apama. Die Werte werden von der getValues()-Aktion des Ereignisses com.apama.correlator.EngineStatus ausgegeben und über das REST-API offengelegt. |
Modellstatus
Die folgenden Informationen werden für jedes aktive Modell veröffentlicht, das derzeit ausgeführt wird oder bei dem ein Fehler aufgetreten ist:
Name | Beschreibung |
mode | Der Modus des aktiven Modells. Für Modelle im Simulationsmodus ist dies SIMULATION. Ansonsten ist es PRODUCTION. |
modeProperties | Alle modusspezifischen Eigenschaften des Modells. Bei Modellen, die im Modus SIMULATION laufen, beinhaltet dies die Start- und Endzeit der Simulation. |
numModelEvaluations | Die Gesamtanzahl der Male, wie oft das Modell seit der Aktivierung ausgewertet wurde. |
numBlockEvaluations | Die Gesamtanzahl der Male, wie oft die Blöcke im Modell seit der Aktivierung des Modells ausgewertet wurden. Dies ist die Summe der Anzahl der Auswertungen für jeden Block im Modell. |
avgBlockEvaluations | Die durchschnittliche Anzahl der Blöcke, die bei jeder Modellauswertung ausgewertet wurden. |
numOutputGenerated | Die Gesamtanzahl der vom Modell generierten Ausgaben seit der Aktivierung des Modells. |
Diese Informationen zu jedem Modell geben einen Einblick in die Leistungsfähigkeit oder den Ablauf der Modelle. Ein Modell mit einer viel größeren Anzahl von numBlockEvaluations als ein anderes Modell kann zum Beispiel signalisieren, dass es die meisten Ressourcen verarbeitet, auch wenn es eine geringe Anzahl von numModelEvaluations hat. In ähnlicher Weise kann dies dazu genutzt werden, um herauszufinden, ob ein Modell seine Ausgaben mit der erwarteten Rate erzeugt - im Verhältnis dazu wie oft es ausgewertet wird.
Sie können den Status mit dem REST-API oder dem Management Interface (EPL-Plug-in) von Apama überwachen. Weitere Informationen finden Sie in den folgenden Abschnitten der englischsprachigen Produktdokumentation von Apama:
"Managing and Monitoring over REST" in
Deploying and Managing Apama Applications, und
"Using the Management interface" in
Developing Apama Applications.
Kettendiagnose
Die folgenden Informationen werden für alle vorhandenen Ketten veröffentlicht:
Name | Beschreibung |
creationTime | Die Zeit, zu der die Kette erstellt wurde. |
executionCount | Die Anzahl der Male, wie oft die Kette ausgewertet wurde. 1 |
modelsInEvalOrder | Eine Liste von Modell-IDs, in der Reihenfolge, in der die Modelle ausgewertet wurden. |
pendingTimersCount | Die Anzahl der ausstehenden Timer, die hinter der aktuellen Zeit liegen. |
maxTime | Die Höchstzeit, die für die Auswertung der Kette benötigt wurde. 1 |
minTime | Die Mindestzeit, die für die Auswertung der Kette benötigt wurde. 1 |
meanTime | Die Durchschnittszeit, die für die Auswertung der Kette benötigt wurde. 1 |
execBucket | Eine Statistik über die Ausführungszeit der Kette. 1, 2 |
1 Die Felder werden aktualisiert, wenn die Kette ganz oder teilweise ausgewertet wird. Bei einer teilweisen Auswertung einer Kette werden nur einige Modelle der Kette ausgewertet.
2 Es gibt 21 Buckets. In den Buckets wird die Anzahl der Male gespeichert, bei denen die Ausführungszeit innerhalb des Bucket-Bereichs liegt. Jeder Bucket hat eine Größe von
timedelay_secs geteilt durch 10 Sekunden, mit Ausnahme des letzten Buckets, der sich bis ins Unendliche erstreckt. Beispiel: Wenn
timedelay_secs 2 Sekunden beträgt, dann enthält der erste Bucket die Anzahl der Male, bei denen die Ausführung der Kette bis zu 0,2 Sekunden dauerte. Der zweite Bucket enthält in diesem Fall die Anzahl der Male, bei denen die Ausführung der Kette mehr als 0,2 Sekunden und bis zu 0,4 Sekunden dauerte. Und so weiter. Siehe auch das folgende Beispiel:
Bucket | Bereich der Ausführungszeit |
1 | 0 - 0,2 |
2 | 0,2 - 0,4 |
3 | 0,4 - 0,6 |
... | ... |
20 | 3,8 - 4,0 |
21 | 4,0 - unendlich |
Status der langsamsten Kette
Wenn Modellketten mit hohem Durchsatz über mehrere Worker hinweg eingesetzt werden, kann es vorkommen, dass eine Kette bei der Verarbeitung der Eingabeereignisse in Rückstand gerät, wodurch ein Rückstandsprotokoll an Eingabeereignissen entsteht, die noch verarbeitet werden müssen. Diese Ketten werden langsame Ketten (englisch: slow chains) genannt. Eine Nachricht wird in das Korrelatorlog geschrieben, wenn die langsamste Kette um mehr als 1 Sekunde verzögert ist. Zum Beispiel:
Analytics Builder chain of models "Model 1", "Model 2", "Model 3" is slow by 3 seconds.
Siehe
Korrelatorlog anzeigen; dort ist beschrieben wo das Korrelatorlog zu finden ist.
Die folgenden Informationen über die langsamste Kette sind auch im periodischen Status verfügbar, der als Cumulocity IoT- Operation oder -Ereignis veröffentlicht wird, im Parameter apama_status:
Name | Beschreibung |
user-analyticsbuilder.slowestChain.models | Alle Modelle, die in der langsamsten Kette enthalten sind. |
user-analyticsbuilder.slowestChain.delaySec | Die Anzahl der Sekunden, um die Kette bei der Verarbeitung der Eingabeereignisse verzögert ist. |
Beispiel
Das folgende Beispiel zeigt die Daten einer Statusoperation, die von Cumulocity IoT veröffentlicht werden:
{
"creationTime": "2021-01-05T21:48:54.620+02:00",
"deviceId": "6518",
"deviceName": "apama_status",
"id": "8579",
"self": "https://myown.iot.com/devicecontrol/operations/8579",
"status": "PENDING",
"models_running": {
"Package Tracking": {
"mode": "SIMULATION",
"modeProperties":{"startTime":1533160604, "endTime":1533160614},
"numModelEvaluations": 68,
"numBlockEvaluations": 967,
"avgBlockEvaluations": 14.2,
"numOutputGenerated": 50
}
},
"models_failed": {
"Build Pipeline ": {
"mode": "PRODUCTION",
"numModelEvaluations": 214,
"numBlockEvaluations": 671,
"avgBlockEvaluations": 3.13,
"numOutputGenerated": 4
}
},
"chain_diagnostics": {
"780858_780858": {
"creationTime": 1600252455.164188,
"executionCount": 4,
"modelsInEvalOrder": ["780858_780858", "780860_780860"],
"pendingTimersCount": 1,
"timeData": {
"execBucket": [2,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
"maxTime": 0.00014781951904296875,
"meanTime": 0.0001152356465657552,
"minTime": 6.29425048828125e-05
}
}
},
"apama_status": {
"user-analyticsbuilder.slowestChain.models": "\"Model 1\", \"Model 2\", \"Model 3\"",
"user-analyticsbuilder.slowestChain.delaySec": "3",
"user-analytics-oldEventsDropped": "1",
"numJavaApplications": "1",
"numMonitors": "27",
"user-httpServer.eventsTowardsHost": "1646",
"numFastTracked": "183",
"user-httpServer.authenticationFailures": "4",
"numContexts": "5",
"slowestReceiverQueueSize": "0",
"numQueuedFastTrack": "0",
"mostBackedUpInputContext": "<none>",
"user-httpServer.failedRequests": "4",
"slowestReceiver": "<none>",
"numInputQueuedInput": "0",
"user-httpServer.staticFileRequests": "0",
"numReceived": "1690",
"user-httpServer.failedRequests.marginal": "1",
"numEmits": "1687",
"numOutEventsUnAcked": "1",
"user-httpServer.authenticationFailures.marginal": "1",
"user-httpServer.status": "ONLINE",
"numProcesses": "48",
"numEventTypes": "228",
"virtualMemorySize": "3177968",
"numQueuedInput": "0",
"numConsumers": "3",
"numOutEventsQueued": "1",
"uptime": "1383561",
"numListeners": "207",
"numOutEventsSent": "1686",
"mostBackedUpICQueueSize": "0",
"numSnapshots": "0",
"mostBackedUpICLatency": "0",
"numProcessed": "1940",
"numSubListeners": "207"
}
}