This workflow follows the Agent → Ollama Chat recipe pattern — see all workflows that pair these two integrations.
The workflow JSON
Copy or download the full n8n JSON below. Paste it into a new n8n workflow, add your credentials, activate. Full import guide →
{
"name": "noc_zabbix_ai_triage_agent",
"nodes": [
{
"parameters": {
"httpMethod": "POST",
"path": "83b79818-c969-4644-957b-64ebe7474177",
"options": {}
},
"type": "n8n-nodes-base.webhook",
"typeVersion": 2.1,
"position": [
0,
0
],
"id": "49d3d9d1-7184-4d59-b93d-7a4f852d2d37",
"name": "Webhook"
},
{
"parameters": {
"promptType": "define",
"text": "=Alerta de Zabbix detectada. Procesa el siguiente payload JSON seg\u00fan tus instrucciones de ingenier\u00eda de NOC:\n{{ JSON.stringify($json.body) }}",
"hasOutputParser": true,
"options": {
"systemMessage": "=# SYSTEM PROMPT: ISP-Copilot NOC Automation Agent (Tier 1/2)\n\n## 1. IDENTITY & ROLE\nYou are \"ISP-Copilot\", an advanced Core Network Operations Center (NOC) automation AI agent. Your mission is to analyze incoming JSON payloads from Zabbix server alerts, correlate them with past telemetry in your Redis memory, and use your interactive SSH tool to run live diagnostics or remediations on network devices before generating a final structured verdict.\n\n## 2. OPERATIONAL ENVIRONMENT & LIVE INTERACTION (REACT FRAMEWORK)\nYou operate in a high-performance ISP environment. When a Zabbix alert arrives, you must NOT assume or guess the current state. You are equipped with an SSH tool (`ejecutar_comando_mikrotik`) to actively query the infrastructure.\n- **Topologies:** MikroTik RouterOS (PCC/ECMP load balancing on RB4011, BGP peers, OSPF, Core switches), GPON/EPON OLTs (Huawei, ZTE, Fiberhome), PPPoE servers, and CGNAT blocks.\n- **Execution Loop:** Upon receiving an alert, immediately evaluate if running a live command (e.g., `/interface print`, `/ping`, `/ip route print`, `/user active print`) will provide critical visibility. Execute the tool, analyze the terminal output, and iterate if necessary before filling the final JSON schema.\n\n## 3. MEMORY CONTEXTUALIZATION (REDIS INTERACTION)\nYou have a persistent chat/event memory mapped per host device. Use it to check if this alert is isolated or part of a continuous pattern:\n- **Flapping Mitigation:** If memory shows the same interface or host has been going UP and DOWN repeatedly in the last few minutes, do NOT attempt automated port flaps or interface resets via your SSH tool. Stop automatic execution and escalate to Category B immediately as a suspected physical layer issue (fiber macro-bend, bad connector, or power instability).\n- **Incident Progression:** If a device previously reported high CPU/Memory and now reports \"Host Unavailable\", correlate them to validate that the host crashed under load.\n\n## 4. INCIDENT CLASSIFICATION & ACTION PROTOCOL\nAfter interacting with the live device via your tool (if needed) and reading the Redis logs, you must classify the outcome into exactly one of three categories:\n\n### CATEGORY A: Automated Diagnosis / Remediation Executed\nApply this if the device was reachable and you successfully executed commands via your SSH tool to either gather advanced troubleshooting data or mitigate a known soft-failure.\n- *Examples:* You successfully cleared a hung PPPoE session, verified routing tables after a flapping route, or ran a live ping test from the core router to isolate a gateway.\n- *Action:* Set `tool_ssh_ejecutada: true`. In the JSON response, detail what you discovered and what actions you executed on the CLI.\n\n### CATEGORY B: Human NOC Escalation (High Impact / Physical Failures)\nApply this if the device is completely down/unreachable via SSH, if critical infrastructure core protocols are broken (BGP down, OLT uplink down), or if your Redis memory flags a critical flapping condition.\n- *Examples:* Backbone fiber cuts, power failures, or devices that reject SSH connections during a critical status change.\n- *Action:* Set `tool_ssh_ejecutada: false` (or true if it failed/timeout) and generate a concise technical summary optimized for network engineers.\n\n### CATEGORY C: Tier 1 Customer Care / Fiber Access Support\nApply this if your analysis (via Zabbix data or OLT queries) confirms the issue only affects isolated end-users, residential ONUs, or local Wi-Fi, without compromising core routing.\n- *Examples:* Individual ONT RX optical power out of range (e.g., < -27 dBm) or local customer wireless interference.\n- *Action:* Set `tool_ssh_ejecutada: false` and generate a ticket/notification summary optimized for helpdesk agents or the end customer.\n\n### \u26a0\ufe0f CRITICAL CLASSIFICATION RULES (NEVER VIOLATE):\n1. **Physical Layer Isolation:** If your live SSH diagnostic or the Zabbix alert suggests a physical failure (e.g., link down, cable disconnected, \"no carrier\", hardware fault, bad fiber optics power), you must NEVER classify it as Category A. Physical issues cannot be fixed with software. Route it to **Category B (escalamiento)** immediately.\n2. **Diagnostic vs. Action:** Running a command just to \"see\" (like `/interface print`) without altering or mitigating the state does NOT count as Category A. If you cannot fix or clear the error autonomously with a decisive command, it is Category B.\n3. **Data Integrity Constraints:** - If `categoria_accion` is 'A' or 'B', `ticket_cliente` MUST be strictly `null`. Never send technical internal port alerts (like ether6 down) to end-users.\n - If `categoria_accion` is 'B' or 'C', `tool_ssh_ejecutada` can be true or false (depending on whether you managed to check), but `registro_comandos_ejecutados` must never contain software-fix actions if the node is dead.\n\n## 5. RESPONSE CONSTRAINT (STRICT JSON OUTPUT)\nYou must ALWAYS respond with a single, valid JSON object. Do not include any conversational text, markdown outside the code block, or preambles. Your response must match this schema exactly:\n\n{\n \"diagnostico_ia\": \"A rigorous engineering explanation of the root cause, incorporating the live data returned by your SSH tool and historical Redis patterns.\",\n \"categoria_accion\": \"A\",\n \"tool_ssh_ejecutada\": true,\n \"registro_comandos_ejecutados\": \"Executed '/interface ethernet print' on Core-RB4011. Found ether3 link down. Attempted clear, interface remained down.\",\n \"notificacion_noc\": \"\ud83d\udd34 **[CORE ALERT]** Host: Core-MikroTik-RB4011 | Issue: Interface ether3 Down | Live Status: Checked via SSH, physical link failure suspected.\",\n \"ticket_cliente\": null\n}\n\nIf `tool_ssh_ejecutada` is false, `registro_comandos_ejecutados` must be strictly null. If `categoria_accion` is not 'C', `ticket_cliente` must be strictly null.\n\n## 6. CONTEXTUAL ACCURACY & ANTI-HALLUCINATION RULES\n1. **Never Inventory Guess:** You do not know the network topology by heart. You MUST strictly read the `trigger_description` and `item_name` fields from the Zabbix JSON to understand what is physically connected to the port (e.g., if it says it is a Server, do NOT invent that it is a Switch).\n2. **Strict Null Enforcement:** If `categoria_accion` is 'B', the field `ticket_cliente` MUST be `null`. No exceptions. You are forbidden from writing messages to end-users if the issue is a core infrastructure or server escalation.\n3. **Tool Logic for Category B:** If you classify an event as 'B' (Escalation), `comando_sugerido` or any active remediation step is useless because a human must go to the site. Keep it focused on the diagnostic report.\n4. **Knowledge Base Usage (Qdrant):** You have access to a Qdrant vector database containing official MikroTik RouterOS manuals, ISP procedures, and engineering guides. When diagnosing an issue (Category A or B), use the retrieved context from Qdrant to formulate the exact CLI syntax and engineering root cause. Do NOT invent RouterOS commands; trust the official documentation retrieved from your knowledge base.",
"maxIterations": 50
}
},
"type": "@n8n/n8n-nodes-langchain.agent",
"typeVersion": 3.1,
"position": [
208,
0
],
"id": "4881a935-498e-446e-a4af-8eb1e7c89d83",
"name": "AI Agent"
},
{
"parameters": {
"sessionIdType": "customKey",
"sessionKey": "={{ $json.body.event_id }}",
"sessionTTL": 3600,
"contextWindowLength": 20
},
"type": "@n8n/n8n-nodes-langchain.memoryRedisChat",
"typeVersion": 1.6,
"position": [
256,
432
],
"id": "189770c9-995d-4e90-9e98-5984194d4d3b",
"name": "Redis Chat Memory",
"credentials": {
"redis": {
"name": "<your credential>"
}
}
},
{
"parameters": {
"model": "hermes3:8b",
"options": {}
},
"type": "@n8n/n8n-nodes-langchain.lmChatOllama",
"typeVersion": 1,
"position": [
80,
432
],
"id": "9a2711d7-d4b8-46f3-a269-354499112813",
"name": "Ollama Chat Model",
"credentials": {
"ollamaApi": {
"name": "<your credential>"
}
}
},
{
"parameters": {
"rules": {
"values": [
{
"conditions": {
"options": {
"caseSensitive": true,
"leftValue": "",
"typeValidation": "strict",
"version": 3
},
"conditions": [
{
"leftValue": "={{ $json.output.categoria_accion }}",
"rightValue": "A",
"operator": {
"type": "string",
"operation": "equals"
},
"id": "79258228-19cf-45b4-87ff-d0033f0c204f"
}
],
"combinator": "and"
},
"renameOutput": true,
"outputKey": "diagnostico"
},
{
"conditions": {
"options": {
"caseSensitive": true,
"leftValue": "",
"typeValidation": "strict",
"version": 3
},
"conditions": [
{
"id": "c17f257a-b571-4dc4-bdc3-817d4156079b",
"leftValue": "={{ $json.output.categoria_accion }}",
"rightValue": "B",
"operator": {
"type": "string",
"operation": "equals",
"name": "filter.operator.equals"
}
}
],
"combinator": "and"
},
"renameOutput": true,
"outputKey": "escalamiento"
},
{
"conditions": {
"options": {
"caseSensitive": true,
"leftValue": "",
"typeValidation": "strict",
"version": 3
},
"conditions": [
{
"id": "053cc3ae-01cb-452d-8696-10fcffba96bd",
"leftValue": "={{ $json.output.categoria_accion }}",
"rightValue": "C",
"operator": {
"type": "string",
"operation": "equals",
"name": "filter.operator.equals"
}
}
],
"combinator": "and"
},
"renameOutput": true,
"outputKey": "cliente"
}
]
},
"options": {}
},
"type": "n8n-nodes-base.switch",
"typeVersion": 3.4,
"position": [
560,
-16
],
"id": "bc788117-05fc-408c-9200-387d4527e689",
"name": "Switch"
},
{
"parameters": {
"schemaType": "manual",
"inputSchema": "{\n \"type\": \"object\",\n \"properties\": {\n \"diagnostico_ia\": {\n \"type\": \"string\",\n \"description\": \"Explicaci\u00f3n t\u00e9cnica detallada y concisa de la causa ra\u00edz de la falla del ISP.\"\n },\n \"categoria_accion\": {\n \"type\": \"string\",\n \"enum\": [\"A\", \"B\", \"C\"],\n \"description\": \"Clasificaci\u00f3n del incidente: A para auto-recuperaci\u00f3n por SSH, B para escalamiento cr\u00edtico al NOC, C para atenci\u00f3n al cliente/Tier 1.\"\n },\n \"requiere_ssh\": {\n \"type\": \"boolean\",\n \"description\": \"Verdadero si se necesita ejecutar un comando de diagn\u00f3stico o mitigaci\u00f3n en el equipo afectado.\"\n },\n \"comando_sugerido\": {\n \"type\": \"string\",\n \"description\": \"Comando exacto de RouterOS o CLI aplicable si requiere_ssh es true. De lo contrario, dejar como string vac\u00edo o null.\"\n },\n \"notificacion_noc\": {\n \"type\": \"string\",\n \"description\": \"Mensaje formateado en Markdown listo para enviar al canal de alertas de los ingenieros del NOC.\"\n },\n \"ticket_cliente\": {\n \"type\": \"string\",\n \"description\": \"Mensaje de texto amigable o estructurado para el helpdesk/cliente final si la categor\u00eda es C. De lo contrario, dejar vac\u00edo.\"\n }\n },\n \"required\": [\n \"diagnostico_ia\",\n \"categoria_accion\",\n \"requiere_ssh\",\n \"comando_sugerido\",\n \"notificacion_noc\",\n \"ticket_cliente\"\n ]\n}",
"autoFix": true
},
"type": "@n8n/n8n-nodes-langchain.outputParserStructured",
"typeVersion": 1.3,
"position": [
496,
224
],
"id": "76e78ffe-4b32-47a6-8679-564add4a6182",
"name": "Structured Output Parser"
},
{
"parameters": {
"descriptionType": "manual",
"toolDescription": "\u00dasala para conectarte v\u00eda SSH al router Core o switches y ejecutar comandos de diagn\u00f3stico (ej. /ping, /interface print, /ip route print) cuando necesites investigar a fondo una alerta de Zabbix",
"host": "10.250.3.1",
"port": 2222,
"username": "sinfallas",
"password": "W34r3th3b0rg1980.",
"command": "={{ /*n8n-auto-generated-fromAI-override*/ $fromAI('Command', `aca colocaras el comando que quieres ejecutar en el equipo`, 'string') }}",
"workingDirectory": ""
},
"type": "n8n-nodes-sshv2.hadidizAiTool",
"typeVersion": 1,
"position": [
432,
432
],
"id": "50ca6512-508e-4865-b628-c951ad35e561",
"name": "ejecutar_comando_mikrotik"
},
{
"parameters": {
"descriptionType": "manual",
"toolDescription": "Use this tool IMMEDIATELY after receiving a Zabbix alert for any interface down, port flapping, or connectivity issue. This tool queries the ISP's physical inventory database to determine the exact topology.\n\nYou MUST provide two inputs based on the Zabbix JSON payload:\n1. 'host_name': The exact name of the equipment (e.g., from {HOST.NAME}).\n2. 'interface_name': The exact name of the affected port (e.g., from the trigger name or item, like 'ether6' or 'sfp1').\n\nThe tool will return the physical context of the port, including what device is connected to the other end ('connected_device_name'), the port's role ('interface_role'), its criticality ('criticidad'), and crucially, a boolean flag ('auto_remediation_allowed'). You MUST read this flag: if it is false, you are STRICTLY FORBIDDEN from running any mitigation commands on that port via SSH, and must escalate to Category B.",
"operation": "get",
"dataTableId": {
"__rl": true,
"value": "wDW7diaOXLnEw8OA",
"mode": "list",
"cachedResultName": "inventario",
"cachedResultUrl": "/projects/ZXPsgeTxhB8igXrb/datatables/wDW7diaOXLnEw8OA"
},
"returnAll": true
},
"type": "n8n-nodes-base.dataTableTool",
"typeVersion": 1.1,
"position": [
432,
624
],
"id": "1505a929-b92d-4de3-9e18-2762f5a1e4f7",
"name": "consultar_inventario_isp"
},
{
"parameters": {
"mode": "retrieve-as-tool",
"toolDescription": "Call this tool every time a user asks you something related to:\n- git\n- Devops\n- Continuous Integration and Continuous Delivery\n- deployments\n- Agile Development\n- Continuous Monitoring\n- Version Control\n- System modeling\n- Software Design\n- Software Design Patterns\n- software development\n- Best practices in programming\n- Web development\n- itil\n- debian\n- ubuntu\n- linux\n- linux firewall\n- linux security\n- linux hardening\n- linux networking\n- linux commands\n- iproute2\n- forensics\n- digital forensics\n- computer forensics\n- searching, analyzing, acquiring, and securing digital evidence\n- OSINT TECHNIQUES\n- malware forensics\n- penetration testing\n- advanced persistent threat hacking\n- exploitation\n- collecting, examining, and preserving evidence of computer crimes.\n- BEST PRACTICES FOR THE PROTECTION AND RESILIENCE OF NETWORK AND INFORMATION SYSTEMS\n- aws security incident response guide\n- aws\n- ec2\n- vpc\n- iam\n- awscli\n- lightsail\n- s3\n- cloudfront\n- route53\n- ebs\n- efs\n- emr\n- ecr\n- ekr\n- zabbix\n- zabbix agent\n- zabbix dashboard\n- zabbix snmp\n- zabbix proxy\n- bash\n- scripting\n- Mikrotik\n- RouterOS\n- Router OS\n- ros\n- RouterBOARD\n- RB\n- BGP\n- iBGP\n- eBGP\n- ospf\n- mpls\n- wireguard\n- Switching\n- MTU\n- VLAN\n- MAC-based VLAN\n- STP\n- RSTP\n- MSTP\n- L2\n- Layer 2\n- IGMP\n- ARP\n- Port Security\n- 802.1x\n- LAG\n- L7-filter\n- QoS\n- networking\n- osi model\n- Python\n- FastAPI\n- microservices with FastAPI\n- python and large language models\n- time series forecasting with python\n- Windows\n- Windows server\n- Windows services\n- Proxmox\n- QEMU\n- KVM\n- LXC\n- virtualization\n- virtual machines\n- ansible\n- semaphore\n- playbooks\n- inventory\n- ansible for devops\n- Asterisk\n- voip\n- sip\n- iax\n- pbx\n- voip trunks\n\nSearches in this vector store must be done in English.",
"qdrantCollection": {
"__rl": true,
"value": "unificado",
"mode": "list",
"cachedResultName": "unificado"
},
"topK": 20,
"useReranker": true,
"options": {}
},
"type": "@n8n/n8n-nodes-langchain.vectorStoreQdrant",
"typeVersion": 1.3,
"position": [
96,
752
],
"id": "664f2dcc-e4ab-4a75-b453-adef674a0588",
"name": "Qdrant Vector Store",
"credentials": {
"qdrantApi": {
"name": "<your credential>"
}
}
},
{
"parameters": {
"model": "nomic-embed-text-v2-moe:latest"
},
"type": "@n8n/n8n-nodes-langchain.embeddingsOllama",
"typeVersion": 1,
"position": [
-48,
912
],
"id": "b55f6086-d9ab-4167-89da-bf383b4b3f39",
"name": "Embeddings Ollama",
"credentials": {
"ollamaApi": {
"name": "<your credential>"
}
}
},
{
"parameters": {},
"type": "@n8n/n8n-nodes-langchain.rerankerCohere",
"typeVersion": 1,
"position": [
144,
912
],
"id": "0579d0b5-c00c-444b-a3bb-bb90d88d19be",
"name": "Reranker Cohere",
"credentials": {
"cohereApi": {
"name": "<your credential>"
}
}
}
],
"connections": {
"Webhook": {
"main": [
[
{
"node": "AI Agent",
"type": "main",
"index": 0
}
]
]
},
"Redis Chat Memory": {
"ai_memory": [
[
{
"node": "AI Agent",
"type": "ai_memory",
"index": 0
}
]
]
},
"Ollama Chat Model": {
"ai_languageModel": [
[
{
"node": "AI Agent",
"type": "ai_languageModel",
"index": 0
},
{
"node": "Structured Output Parser",
"type": "ai_languageModel",
"index": 0
}
]
]
},
"AI Agent": {
"main": [
[
{
"node": "Switch",
"type": "main",
"index": 0
}
]
]
},
"Structured Output Parser": {
"ai_outputParser": [
[
{
"node": "AI Agent",
"type": "ai_outputParser",
"index": 0
}
]
]
},
"ejecutar_comando_mikrotik": {
"ai_tool": [
[
{
"node": "AI Agent",
"type": "ai_tool",
"index": 0
}
]
]
},
"consultar_inventario_isp": {
"ai_tool": [
[
{
"node": "AI Agent",
"type": "ai_tool",
"index": 0
}
]
]
},
"Qdrant Vector Store": {
"ai_tool": [
[
{
"node": "AI Agent",
"type": "ai_tool",
"index": 0
}
]
]
},
"Embeddings Ollama": {
"ai_embedding": [
[
{
"node": "Qdrant Vector Store",
"type": "ai_embedding",
"index": 0
}
]
]
},
"Reranker Cohere": {
"ai_reranker": [
[
{
"node": "Qdrant Vector Store",
"type": "ai_reranker",
"index": 0
}
]
]
}
},
"active": true,
"settings": {
"executionOrder": "v1",
"binaryMode": "separate"
},
"versionId": "1c40aae1-e152-44d6-badd-c4ccac7717cd",
"meta": {
"templateCredsSetupCompleted": true
},
"id": "F5rangSHZVHF7YXd",
"tags": []
}
Credentials you'll need
Each integration node will prompt for credentials when you import. We strip credential IDs before publishing — you'll add your own.
cohereApiollamaApiqdrantApiredis
Pro
For the full experience including quality scoring and batch install features for each workflow upgrade to Pro
About this workflow
noc_zabbix_ai_triage_agent. Uses agent, memoryRedisChat, lmChatOllama, outputParserStructured. Webhook trigger; 11 nodes.
Source: https://github.com/tecno-consultores/ISP-Copilot/blob/main/n8n/workflows/noc_zabbix_ai_triage_agent.json — original creator credit. Request a take-down →
Related workflows
Workflows that share integrations, category, or trigger type with this one. All free to copy and import.
This workflow automates compliance validation between a policy/procedure and a corresponding uploaded document. It leverages an AI agent to determine whether the content of the document aligns with th
HTTP Request, Ollama Embeddings, Qdrant Vector Store +5
Indexation. Uses formTrigger, embeddingsOllama, textSplitterRecursiveCharacterTextSplitter, modelSelector. Event-driven trigger; 25 nodes.
Form Trigger, Ollama Embeddings, Text Splitter Recursive Character Text Splitter +9
Larry Llama. Uses agent, lmChatOllama, memoryPostgresChat, embeddingsOllama. Webhook trigger; 17 nodes.
Agent, Ollama Chat, Memory Postgres Chat +6
Indexation. Uses formTrigger, embeddingsOllama, textSplitterRecursiveCharacterTextSplitter, modelSelector. Event-driven trigger; 36 nodes.
Form Trigger, Ollama Embeddings, Text Splitter Recursive Character Text Splitter +10
RAG Agent Integration Hub mit Knowledge Management. Uses memoryPostgresChat, lmChatOllama, lmOllama, toolVectorStore. Chat trigger; 27 nodes.
Memory Postgres Chat, Ollama Chat, Lm Ollama +8