ساخت AI Log Analyzer روی VPS؛ تحلیل هوشمند لاگ‌های Linux، Docker و NGINX با Ollama و گزارش خودکار خطا

چرا AI Log Analyzer برای مدیریت VPS کاربردی است؟

وقتی یک سرور کوچک است، بررسی لاگ‌ها با grep، journalctl و docker logs معمولاً کافی است. مشکل زمانی شروع می‌شود که تعداد سرویس‌ها زیاد شود. در این حالت ممکن است یک خطای NGINX، ری‌استارت Docker، پر شدن دیسک، خطای PHP یا مشکل اتصال به دیتابیس تقریباً هم‌زمان اتفاق بیفتد.

خود لاگ معمولاً فقط یک نشانه را نشان می‌دهد. مثلاً عبارت connection refused به‌تنهایی مشخص نمی‌کند سرویس مقصد خاموش بوده، پورت اشتباه بوده، کانتینر دوباره اجرا شده یا سرویس قبل از آماده‌شدن درخواست دریافت کرده است.

اینجا مدل زبانی می‌تواند به‌عنوان یک لایه تحلیلی عمل کند. هدف این پروژه جایگزین کردن مانیتورینگ حرفه‌ای یا مهندس سیستم نیست؛ بلکه هدف، تبدیل حجم زیادی از متن فنی به یک گزارش اولویت‌بندی‌شده برای عیب‌یابی است.

معماری AI Log Analyzer که در این آموزش می‌سازیم

معماری را عمداً ساده و قابل‌نگهداری انتخاب می‌کنیم. به‌جای اینکه کانتینر تحلیلگر مستقیماً به Docker Socket دسترسی داشته باشد، یک Collector روی خود میزبان لاگ‌ها را جمع می‌کند و فقط فایل‌های خروجی در اختیار سرویس AI قرار می‌گیرند.

این طراحی یک مزیت امنیتی مهم دارد: برنامه AI نیازی به دسترسی مستقیم به Docker Socket ندارد. Docker مستند کرده است که logging driverها روش اصلی مدیریت لاگ کانتینرها هستند و همچنین هشدار داده که دسترسی مستقیم ابزارهای خارجی به فایل‌های داخلی بعضی logging driverها می‌تواند مشکل‌ساز شود. بنابراین در این آموزش از docker logs برای جمع‌آوری خروجی استفاده می‌کنیم.

منابع رسمی برای بررسی بیشتر:
مستندات Docker Logging
و
تنظیم Logging Driver.

جدول اجزای پروژه

چه VPS برای AI Log Analyzer مناسب است؟

برای این پروژه دو منبع متفاوت داریم. خود Collector و FastAPI منابع کمی می‌خواهند، اما مدل زبانی می‌تواند بخش اصلی RAM یا VRAM را مصرف کند. بنابراین انتخاب VPS باید بر اساس مدل مورد استفاده انجام شود.

این اعداد نسخه سخت‌افزاری قطعی نیستند. مقدار RAM و VRAM به مدل، quantization، context length و تعداد درخواست‌ها بستگی دارد. برای یک Collector سبک ممکن است VPS معمولی کافی باشد، اما اجرای مدل بزرگ روی همان سرور می‌تواند نیاز سخت‌افزاری را چند برابر کند.

مرحله اول: آماده‌سازی Ubuntu روی VPS

برای آموزش از Ubuntu 24.04 استفاده می‌کنیم. ساختار دستورات برای بسیاری از نسخه‌های جدید Ubuntu مشابه است، اما مسیر لاگ‌ها و ابزارهای مدیریت سرویس ممکن است در توزیع‌های دیگر مانند Debian، Rocky Linux، AlmaLinux، Fedora Server، RHEL یا openSUSE متفاوت باشد.

ابتدا سیستم را به‌روزرسانی کنید:

apt update && apt upgrade -y

سپس ابزارهای پایه را نصب کنید:

apt install -y curl git ca-certificates jq python3 python3-pip

مرحله دوم: نصب Docker و Docker Compose

در این معماری Ollama و سرویس تحلیلگر را داخل Docker اجرا می‌کنیم. FastAPI نیز در یک image جداگانه قرار می‌گیرد. مستندات FastAPI استفاده از Docker برای بسته‌بندی برنامه را به‌عنوان یکی از روش‌های رایج deployment توضیح می‌دهد.

راهنمای رسمی:
FastAPI در Docker.

اگر Docker روی سرور نصب نیست، ابتدا آن را طبق مستندات رسمی Docker نصب کنید. پس از نصب وضعیت را بررسی کنید:

docker --version
docker compose version

مرحله سوم: ساخت پوشه پروژه AI Log Analyzer

mkdir -p /opt/ai-log-analyzer/app
mkdir -p /opt/ai-log-analyzer/data/docker
cd /opt/ai-log-analyzer

ساختار نهایی پروژه تقریباً به شکل زیر خواهد بود:

/opt/ai-log-analyzer/
├── app/
│   ├── main.py
│   ├── Dockerfile
│   └── requirements.txt
├── data/
│   ├── system.log
│   ├── nginx-access.log
│   ├── nginx-error.log
│   └── docker/
├── collector.sh
├── compose.yml
└── .env

مرحله چهارم: اجرای Ollama روی VPS

Ollama یک API محلی برای اجرای مدل‌ها ارائه می‌کند. در API محلی، endpoint اصلی در حالت معمول روی پورت 11434 قرار دارد و برنامه‌ها می‌توانند از طریق HTTP با مدل ارتباط برقرار کنند.

مستندات رسمی API:
Ollama API Documentation.

برای مدل اولیه می‌توان از یک مدل سبک‌تر شروع کرد. نام مدل را در فایل Compose قابل تغییر می‌گذاریم تا بعداً بتوانید مدل مناسب سخت‌افزار خود را انتخاب کنید.

ساخت فایل compose.yml

services:

  ollama:
    image: ollama/ollama:latest
    container_name: ai-log-ollama
    restart: unless-stopped
    volumes:
      - ollama_data:/root/.ollama
    expose:
      - "11434"

  analyzer:
    build:
      context: ./app
    container_name: ai-log-analyzer
    restart: unless-stopped
    environment:
      OLLAMA_URL: http://ollama:11434
      OLLAMA_MODEL: ${OLLAMA_MODEL}
    depends_on:
      - ollama
    ports:
      - "127.0.0.1:8088:8000"
    volumes:
      - ./data:/logs:ro

volumes:
  ollama_data:

در این ساختار پورت Ollama مستقیماً روی اینترنت منتشر نشده است. این موضوع برای یک سرویس داخلی مهم است؛ زیرا API محلی Ollama در حالت عادی احراز هویت عمومی ندارد و بهتر است آن را بی‌دلیل روی IP عمومی قرار ندهید.

ساخت فایل .env

OLLAMA_MODEL=gemma4:e2b

مدل را می‌توانید بعداً تغییر دهید. انتخاب مدل باید بر اساس RAM، VRAM، سرعت موردنیاز و حجم لاگ‌هایی که قرار است تحلیل شوند انجام شود.

مرحله پنجم: ساخت Collector برای Linux، Docker و NGINX

Collector مهم‌ترین بخش امنیتی این طراحی است. به‌جای اینکه API تحلیلگر اجازه دسترسی مستقیم به سیستم را داشته باشد، یک اسکریپت محدود روی Host اجرا می‌شود و فقط داده موردنیاز را داخل پوشه پروژه می‌نویسد.

فایل زیر را ایجاد کنید:

nano /opt/ai-log-analyzer/collector.sh

محتوای آن:

#!/usr/bin/env bash

set -u

BASE="/opt/ai-log-analyzer/data"

mkdir -p "$BASE/docker"

# Linux / systemd
journalctl -p warning..alert --since "15 minutes ago" --no-pager \
  > "$BASE/system.log" 2>/dev/null || true

# Docker containers
docker ps --format '{{.Names}}' | while read -r container; do
    safe_name=$(printf '%s' "$container" | tr '/ ' '__')

    docker logs \
      --since 15m \
      --timestamps \
      "$container" \
      > "$BASE/docker/${safe_name}.log" 2>&1 || true
done

# NGINX
if [ -f /var/log/nginx/error.log ]; then
    tail -n 500 /var/log/nginx/error.log \
      > "$BASE/nginx-error.log" 2>/dev/null || true
fi

if [ -f /var/log/nginx/access.log ]; then
    tail -n 500 /var/log/nginx/access.log \
      > "$BASE/nginx-access.log" 2>/dev/null || true
fi

اسکریپت را اجرایی کنید:

chmod 700 /opt/ai-log-analyzer/collector.sh
/opt/ai-log-analyzer/collector.sh

برای اطلاعات رسمی درباره logging در NGINX:
راهنمای Logging در NGINX.

مرحله ششم: ساخت API تحلیلگر با FastAPI

حالا برنامه‌ای می‌سازیم که فایل‌های لاگ را می‌خواند، حجم آن‌ها را کنترل می‌کند و متن را به Ollama ارسال می‌کند. برای اینکه prompt بیش از حد بزرگ نشود، از هر فایل فقط تعداد محدودی خط خوانده می‌شود.

فایل requirements.txt

fastapi
uvicorn[standard]
requests

فایل main.py

import os
from pathlib import Path

import requests
from fastapi import FastAPI, HTTPException

app = FastAPI(
    title="AI Log Analyzer",
    version="1.0.0"
)

LOG_ROOT = Path("/logs")
OLLAMA_URL = os.getenv("OLLAMA_URL", "http://ollama:11434")
MODEL = os.getenv("OLLAMA_MODEL", "gemma4:e2b")

MAX_LINES_PER_FILE = 250
MAX_TOTAL_CHARS = 28000


def read_log_file(path: Path) -> str:
    try:
        lines = path.read_text(
            encoding="utf-8",
            errors="replace"
        ).splitlines()

        return "\n".join(lines[-MAX_LINES_PER_FILE:])

    except Exception as exc:
        return f"[read-error] {path.name}: {exc}"


def collect_logs() -> str:
    chunks = []
    total = 0

    if not LOG_ROOT.exists():
        return "No log directory found."

    for path in sorted(LOG_ROOT.rglob("*.log")):

        content = read_log_file(path)

        if not content.strip():
            continue

        section = (
            f"\n===== SOURCE: {path.relative_to(LOG_ROOT)} =====\n"
            f"{content}\n"
        )

        remaining = MAX_TOTAL_CHARS - total

        if remaining <= 0:
            break

        section = section[:remaining]
        chunks.append(section)
        total += len(section)

    if not chunks:
        return "No readable log data found."

    return "".join(chunks)


def build_prompt(logs: str) -> str:
    return f"""
You are a Linux, Docker and NGINX incident analyst.

Analyze the following server logs.

Your job is NOT to invent facts.
Only use evidence visible in the logs.

Return the report in Persian with these sections:

1. خلاصه وضعیت
2. خطاهای مهم
3. سطح شدت هر خطا: Critical / High / Medium / Low
4. شواهد موجود در لاگ
5. علت احتمالی
6. مواردی که هنوز نیاز به بررسی دارند
7. دستورات پیشنهادی برای بررسی بیشتر
8. راهکار پیشنهادی
9. آیا احتمال ارتباط بین چند خطا وجود دارد؟

Important:
- Never claim certainty when the logs are insufficient.
- Never suggest destructive commands without a warning.
- Do not expose secrets if they appear in logs.
- Treat IP addresses, tokens, passwords and cookies as sensitive.
- Prefer read-only diagnostic commands.

LOG DATA:
{logs}
"""


@app.get("/")
def root():
    return {
        "service": "AI Log Analyzer",
        "status": "running"
    }


@app.get("/analyze")
def analyze():
    logs = collect_logs()

    if not logs.strip():
        raise HTTPException(
            status_code=404,
            detail="No logs found"
        )

    prompt = build_prompt(logs)

    payload = {
        "model": MODEL,
        "messages": [
            {
                "role": "user",
                "content": prompt
            }
        ],
        "stream": False,
        "options": {
            "temperature": 0
        }
    }

    try:
        response = requests.post(
            f"{OLLAMA_URL}/api/chat",
            json=payload,
            timeout=300
        )

        response.raise_for_status()

        data = response.json()

        return {
            "model": MODEL,
            "report": data.get(
                "message",
                {}
            ).get(
                "content",
                ""
            )
        }

    except requests.RequestException as exc:
        raise HTTPException(
            status_code=502,
            detail=f"Ollama request failed: {exc}"
        )

در این برنامه از endpoint /api/chat استفاده شده است. Ollama امکان غیرفعال کردن streaming با stream:false را فراهم می‌کند و پاسخ نهایی را در بخش پیام برمی‌گرداند.

ساخت Dockerfile

FROM python:3.13-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY main.py .

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

این ساختار مشابه الگوی رایج اجرای FastAPI داخل container است؛ وابستگی‌ها ابتدا نصب می‌شوند و سپس فایل برنامه وارد image می‌شود.

مرحله هفتم: ساخت و اجرای سرویس‌ها

cd /opt/ai-log-analyzer

docker compose build
docker compose up -d

وضعیت کانتینرها را بررسی کنید:

docker compose ps

اکنون باید Ollama و Analyzer در وضعیت running باشند.

مرحله هشتم: دانلود مدل در Ollama

ابتدا وارد container Ollama شوید و مدل انتخابی را دریافت کنید:

docker exec -it ai-log-ollama ollama pull gemma4:e2b

سپس مدل‌های نصب‌شده را ببینید:

docker exec -it ai-log-ollama ollama list

مرحله نهم: تست مستقیم Ollama

قبل از تست Analyzer، مطمئن شوید خود مدل پاسخ می‌دهد:

docker exec ai-log-ollama sh -c \
'curl -s http://localhost:11434/api/chat \
-H "Content-Type: application/json" \
-d '\''{
  "model":"gemma4:e2b",
  "messages":[
    {
      "role":"user",
      "content":"Explain this Linux error briefly: connection refused"
    }
  ],
  "stream":false
}'

اگر JSON پاسخ دریافت کردید، بخش AI آماده است.

مرحله دهم: اجرای اولین تحلیل لاگ

ابتدا Collector را اجرا کنید تا داده جدید وارد پوشه پروژه شود:

/opt/ai-log-analyzer/collector.sh

سپس Analyzer را صدا بزنید:

curl http://127.0.0.1:8088/analyze

اگر همه چیز درست باشد، پاسخ JSON شامل گزارش فارسی AI خواهد بود.

مرحله یازدهم: تحلیل خودکار لاگ‌های Docker

Collector نام تمام containerهای در حال اجرا را پیدا می‌کند و برای هرکدام خروجی docker logs را در یک فایل جدا ذخیره می‌کند. این کار برای سرویس‌هایی مانند NGINX، Node.js، PHP، Redis، PostgreSQL و APIهای داخلی کاربردی است.

برای بررسی دستی نیز می‌توانید از دستور زیر استفاده کنید:

docker ps --format "table {{.Names}}\t{{.Status}}"

docker logs --since 15m --timestamps CONTAINER_NAME

Docker توضیح می‌دهد که docker logs خروجی STDOUT و STDERR کانتینر را نمایش می‌دهد و رفتار واقعی آن به نحوه تولید لاگ توسط برنامه داخل container وابسته است.

مرحله دوازدهم: تحلیل لاگ NGINX

NGINX معمولاً دو نوع داده بسیار مهم در اختیار شما قرار می‌دهد: Access Log برای درخواست‌ها و Error Log برای خطاها و رخدادهای مهم.

برای مثال، اگر کاربران با خطای 502 مواجه شوند، ترکیب access log و error log می‌تواند سرنخ مهمی درباره upstream، timeout یا connection refused ایجاد کند.

grep -Ei "502|503|504|timeout|refused|upstream|connect" \
/var/log/nginx/error.log | tail -n 100

برای access log نیز می‌توانید خطاهای HTTP را جدا کنید:

awk '$9 ~ /^(4|5)/ {print}' \
/var/log/nginx/access.log | tail -n 100

مرحله سیزدهم: اجرای Collector به‌صورت خودکار

اجرای دستی برای تست مناسب است، اما یک AI Log Analyzer واقعی باید مرتب داده تازه دریافت کند. برای این کار از systemd timer استفاده می‌کنیم.

ساخت سرویس

nano /etc/systemd/system/ai-log-collector.service

[Unit]
Description=AI Log Analyzer Collector
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
ExecStart=/opt/ai-log-analyzer/collector.sh

ساخت Timer

nano /etc/systemd/system/ai-log-collector.timer

[Unit]
Description=Run AI Log Analyzer Collector every 5 minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min
Persistent=true

[Install]
WantedBy=timers.target

سرویس را فعال کنید:

systemctl daemon-reload
systemctl enable --now ai-log-collector.timer

systemctl status ai-log-collector.timer
systemctl list-timers --all | grep ai-log

مرحله چهاردهم: ساخت گزارش قابل‌فهم برای تیم فنی

یکی از مهم‌ترین قسمت‌های پروژه، prompt است. اگر فقط بگوییم «این لاگ را تحلیل کن»، مدل ممکن است گزارش طولانی و نامنظم بدهد. در عوض باید خروجی را به قالب ثابت تبدیل کنیم.

چطور AI Log Analyzer را دقیق‌تر کنیم؟

۱. لاگ‌ها را قبل از ارسال فشرده کنید

ارسال چند صد مگابایت لاگ به مدل تصمیم خوبی نیست. ابتدا با ابزارهای سنتی داده را محدود کنید. برای نمونه فقط 4xx و 5xx یا فقط خطاهای 15 دقیقه اخیر را ارسال کنید.

۲. لاگ‌ها را بر اساس منبع جدا کنید

قرار دادن systemd، Docker و NGINX در یک متن بدون مشخص کردن منبع، احتمال برداشت اشتباه را بالا می‌برد. در پروژه ما برای هر فایل یک عنوان SOURCE ایجاد می‌شود.

۳. خروجی ساختاریافته استفاده کنید

Ollama از structured outputs پشتیبانی می‌کند. در نسخه پیشرفته می‌توانید به‌جای متن آزاد، JSON Schema تعریف کنید تا خروجی همیشه شامل فیلدهایی مانند severity، service، evidence و recommendation باشد.

برای توسعه این بخش:
مستندات Structured Outputs در Ollama.

۴. برای هر سرویس prompt اختصاصی داشته باشید

تحلیل خطای NGINX با تحلیل PostgreSQL یکسان نیست. در نسخه حرفه‌ای می‌توانید برای هر منبع prompt جداگانه تعریف کنید. مثلاً تحلیلگر NGINX روی upstream و status code تمرکز کند و تحلیلگر Docker روی restart، exit code و dependencyها تمرکز داشته باشد.

چه خطاهایی را می‌توان با این سیستم پیدا کرد؟

یک مثال واقعی از تحلیل خطای 502

فرض کنید NGINX چنین خطایی ثبت کرده باشد:

2026/10/01 11:30:14 [error] 1234#1234:
*42 connect() failed (111: Connection refused)
while connecting to upstream,
client: 192.0.2.15,
server: example.com,
request: "GET /api HTTP/1.1",
upstream: "http://127.0.0.1:8000/api"

AI نباید فقط بگوید «NGINX خراب است». شواهد نشان می‌دهند NGINX هنگام اتصال به upstream روی پورت 8000 با Connection refused مواجه شده است. بنابراین مسیر بررسی منطقی، وضعیت برنامه روی پورت 8000، وضعیت container یا process مربوطه و زمان restart آن است.

ss -lntp | grep ':8000'

docker ps

docker compose ps

systemctl --failed

این نوع خروجی ارزش AI را نشان می‌دهد: مدل به‌جای ارائه یک دستور تصادفی، می‌تواند چند منبع لاگ را کنار هم قرار دهد و مسیر بررسی را کوتاه‌تر کند.

مرحله پانزدهم: قرار دادن Analyzer پشت NGINX

در محیط واقعی بهتر است API را مستقیماً روی اینترنت باز نکنید. می‌توانید آن را روی 127.0.0.1:8088 نگه دارید و NGINX را به‌عنوان reverse proxy در جلوی آن قرار دهید.

نمونه کانفیگ:

server {
    listen 443 ssl http2;
    server_name logs.example.com;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

در این حالت HTTPS را روی NGINX مدیریت می‌کنید و سرویس FastAPI همچنان فقط روی localhost قابل‌دسترسی است.

امنیت AI Log Analyzer؛ مهم‌تر از خود AI

لاگ‌ها ممکن است اطلاعاتی داشته باشند که نباید در اختیار مدل یا کاربر نهایی قرار بگیرند. IP، token، cookie، API key، session ID، ایمیل و اطلاعات احراز هویت نمونه‌هایی از داده‌هایی هستند که باید قبل از تحلیل عمومی یا اشتراک‌گذاری پاک شوند.

آیا می‌توان AI Log Analyzer را به چند VPS متصل کرد؟

بله. نسخه‌ای که در این آموزش ساختیم برای یک VPS طراحی شده است، اما معماری را می‌توان توسعه داد. در مدل چندسروری، هر VPS یک Collector سبک اجرا می‌کند و فقط داده‌های موردنیاز را به یک سرور مرکزی تحلیل ارسال می‌کند.

این مدل برای شرکت‌هایی که چند سرور وب، API، دیتابیس یا Docker Host دارند جذاب‌تر است؛ زیرا به‌جای ورود دستی به هر VPS، می‌توان تحلیل را از یک نقطه انجام داد.

نسخه حرفه‌ای‌تر: ترکیب AI با RAG و دانش داخلی

مرحله بعدی پروژه می‌تواند اضافه کردن مستندات داخلی باشد. مثلاً اگر تیم شما برای هر سرویس Runbook مشخصی دارد، آن اسناد را در یک پایگاه دانش قرار دهید و هنگام تحلیل خطا، بخش مرتبط را به مدل بدهید.

در چنین ساختاری AI فقط نمی‌گوید «احتمالاً سرویس upstream مشکل دارد»، بلکه می‌تواند بر اساس Runbook داخلی بگوید ابتدا چه مواردی باید بررسی شوند و ترتیب استاندارد عیب‌یابی چیست.

Ollama از embedding نیز پشتیبانی می‌کند و این قابلیت می‌تواند در پروژه‌های RAG برای بازیابی محتوای مرتبط مورد استفاده قرار گیرد.

خطاهای رایج هنگام ساخت AI Log Analyzer

مدل پاسخ نمی‌دهد

ابتدا وضعیت Ollama را بررسی کنید:

docker compose ps
docker logs ai-log-ollama --tail 100

Analyzer به Ollama وصل نمی‌شود

از داخل شبکه Compose نام سرویس باید قابل resolve باشد. در این آموزش نام سرویس ollama است.

docker exec -it ai-log-analyzer python -c \
"import requests; print(requests.get('http://ollama:11434/api/tags').text)"

تحلیل لاگ بسیار کند است

اول حجم prompt را کاهش دهید. سپس RAM و CPU را بررسی کنید. اگر مدل روی CPU اجرا می‌شود، انتظار پاسخ سریع مشابه یک API ابری را نداشته باشید.

free -h
top
df -h
docker stats

لاگ Docker پیدا نمی‌شود

ممکن است container از logging driver یا تنظیمی استفاده کند که رفتار آن با حالت پیش‌فرض فرق دارد. ابتدا وضعیت logging driver را بررسی کنید:

docker info --format '{{.LoggingDriver}}'

docker inspect -f '{{.HostConfig.LogConfig.Type}}' CONTAINER_NAME

Docker در مستندات خود توضیح می‌دهد که driver پیش‌فرض معمولاً json-file است، اما driverهای دیگری مانند local، journald، syslog و موارد دیگر نیز وجود دارند.

بهبود عملکرد برای VPSهای ضعیف‌تر

اگر VPS شما GPU ندارد، به‌جای ارسال حجم زیادی از لاگ، ابتدا با ابزارهای Linux داده را خلاصه کنید. برای نمونه، تعداد خطاهای پرتکرار را بشمارید.

grep -Ei "error|critical|failed|timeout|refused|denied" \
/var/log/nginx/error.log \
| tail -n 300

همچنین می‌توانید به‌جای تحلیل مداوم، فقط زمانی AI را اجرا کنید که تعداد خطاها از یک حد مشخص عبور کند. این مدل هزینه CPU و inference را کاهش می‌دهد.

اگر GPU داشته باشیم چه تغییری ایجاد می‌شود؟

در پروژه‌های کوچک GPU ضروری نیست. اما اگر چند VPS یا حجم زیادی از لاگ را به‌صورت هم‌زمان تحلیل می‌کنید، GPU می‌تواند زمان inference را کاهش دهد. Docker Compose نیز امکان تعریف GPU device reservation برای سرویس‌ها را دارد.

راهنمای رسمی:
GPU Support در Docker Compose.

در چنین سناریویی می‌توان سرویس Ollama را روی یک GPU VPS قرار داد و Collectorهای چند سرور را به آن متصل کرد. این معماری برای ساخت یک سرویس داخلی AI Observability نیز قابل توسعه است.

آیا این پروژه جایگزین Grafana، Loki یا ELK است؟

خیر. این پروژه هدف متفاوتی دارد. ابزارهای کلاسیک Observability برای ذخیره‌سازی، جست‌وجو، متریک، داشبورد و مانیتورینگ در مقیاس بالا طراحی شده‌اند. AI Log Analyzer در این معماری یک لایه تحلیل معنایی روی داده‌های لاگ ایجاد می‌کند.

در یک زیرساخت حرفه‌ای حتی می‌توان این ابزارها را کنار هم قرار داد: Loki برای ذخیره و جست‌وجو، Grafana برای داشبورد و AI برای تحلیل معنایی رخدادها.

مسیر توسعه این پروژه به یک AI Agent واقعی

اگر بخواهید پروژه را از یک Analyzer به یک Agent تبدیل کنید، می‌توانید مرحله‌به‌مرحله قابلیت‌های بیشتری اضافه کنید. اما دسترسی Agent به Shell باید بسیار محدود و کنترل‌شده باشد.

این تفکیک مهم است. تحلیل لاگ یک کار کم‌ریسک‌تر است، اما دادن Shell و دسترسی فایل به یک Agent می‌تواند سطح حمله را به‌شدت افزایش دهد.

چک‌لیست نهایی راه‌اندازی