מאת מדריך התקנה עצמית של Superlog לניהול לוגים מבוסס AI
למדו כיצד להריץ את Superlog על שרת VPS עצמאי. המדריך מפרט את השימוש ב-Docker Compose, הגדרת OTLP ופתרון בעיות בגרסאות ללא תגיות release ב-GitHub עבור ניטור חכם.
מה כוללת התקנה עצמית של Superlog
כדי לארח את Superlog באופן עצמאי, עליכם לשכפל את ה-repository, להעלות את Postgres, ClickHouse ו-OpenTelemetry collector באמצעות Docker Compose, להריץ migration אחד למסד הנתונים, ולאחר מכן להפעיל ארבעה שירותי Node מתוך קוד המקור. היישומים שלכם שולחים traces, לוגים ומדדים בפרוטוקול OTLP (OpenTelemetry protocol) לפורט קליטה, Superlog מבצע להם fingerprinting, מקבץ אירועים חוזרים לתקרית אחת, וסוכן כותב את שלב המיון הראשוני. ההתקנה אורכת אחר-צהריים אחד. כדאי לקרוא על טביעת הרגל של המערכת ועל המגבלות המוצהרות שלה לפני שמתחילים.
Superlog מופץ תחת רישיון Apache 2.0 וזמין בכתובת github.com/superloglabs/superlog. נכון לאוגוסט 2026, יש לו כ-1.2k כוכבים, בערך 460 commits ב-main, וללא תגיות release כלל. הנקודה האחרונה משפיעה על ההתקנה: ב-git checkout v1.0.0 אין מה לבדוק (checkout), לכן עליכם לקבע commit בעצמכם או להריץ את מה שהיה ב-main בבוקר שבו ביצעתם את ה-clone.
מה Superlog מספק ש-Uptime Kuma ו-Langfuse אינם מספקים
כלי ניטור ב-self-hosted נראים זהים מבחוץ, אך הם אינם כאלה. הרצת הכלי הלא נכון גוזלת משאבי שרת ללא תועלת.
- Uptime Kuma בודק את נקודות הקצה שלכם מבחוץ ועונה על שאלה אחת: האם השירות זמין.
- Zabbix מנטר מארחים ושירותים על Ubuntu 24.04, תוך מעקב אחר CPU, זיכרון, דיסק ומצב שירותים בהתאם לספים שהגדרתם.
- Langfuse עוקב אחר קריאות LLM, ומתעד את ה-prompt, המודל, ה-tokens, ה-latency והעלות של כל קריאה.
- Superlog לוקח את הטלמטריה שהשירותים הרגילים שלכם כבר מפיקים והופך כשלים חוזרים לאירועים (incidents).
Superlog עונה על שאלה שונה: משהו התקלקל, מה התקלקל, ומדוע. אין לו דעה על קריאות LLM והוא אינו מבצע בדיקות מבחוץ. הוא קולט נתוני OTLP מקוד היישום הרגיל שלכם ומציב סוכן בשלב המיון (triage), שהוא הצעד הראשון שאדם בתורנות היה מבצע בכל מקרה.
ההבחנה הקריטית עבור תקציב ה-VPS היא האחסון. Uptime Kuma רץ היטב על 1 GB של RAM מכיוון שהוא מאחסן כמה אלפי תוצאות בדיקה. Superlog נושא בתוכו column store, מכיוון שטלמטריה נכתבת פעם אחת ואז נשלפת לפי טווחי זמן על פני מיליוני שורות. זהו הייעוד של ClickHouse, וזהו אינו הייעוד של Postgres. Postgres עדיין נמצא ב-stack, ומחזיק את הנתונים היחסיים הקטנים: פרויקטים, משתמשים, אירועים ומפתחות קליטה (ingest keys).
מה הפקודה docker compose up -d מפעילה בפועל?
שלוש מכולות, ואף אחת מהן אינה Superlog. זה מפתיע אנשים שמצפים להתקנה בפקודה אחת.
postgres:16, מפורסם בפורט המארח 5434clickhouse/clickhouse-server:26.1, בפורט 8123 עבור HTTP ובפורט 9000 עבור הפרוטוקול המקוריotel/opentelemetry-collector-contrib:0.150.1, בפורט 4317 עבור gRPC ובפורט 4318 עבור OTLP על גבי HTTP
יישומי Superlog רצים על המארח, מתוך קוד המקור, ומופעלים על ידי pnpm dev. נכון לאוגוסט 2026, אין קובץ compose לייצור במאגר, לכן התקנה לטווח ארוך מחייבת יצירת יחידות systemd משלכם סביב סקריפט ה-start של כל יישום, או שימוש ב-Dockerfiles הייעודיים לכל יישום שמגיעים עם התוכנה.
שמרו בזיכרון את הנתיב שעובר ה-span, כיוון שכל כשל בהמשך הוא שבירה של אחת החוליות בנתיב זה. היישום שלכם שולח OTLP ל-proxy הקליטה של Superlog. ה-proxy מאמת את הבקשה באמצעות מפתח הקליטה (ingest key) שלכם, מוסיף לה את מזהה הפרויקט, ומעביר אותה ל-collector. ה-collector מסיר כל מאפיין superlog.* שהלקוח ניסה להגדיר, מוסיף superlog.project_id מה-header שסיפק ה-proxy, מבצע batching, וכותב ל-ClickHouse. לאחר מכן, יישום ה-web וה-API קוראים את הנתונים הטלמטריים בחזרה מ-ClickHouse ואת כל השאר מ-Postgres.
הסרת המאפיינים הזו היא בקרת ריבוי-דיירים (multi-tenancy) אמיתית, לא קישוט. בלעדיה, כל מי שמחזיק במפתח קליטה תקף יכול להגדיר בעצמו superlog.project_id ולכתוב לתוך הנתונים של פרויקט אחר.
מה צריך להיות גודל ה-VPS?
תכננו עבור 4 vCPU, 8 GB של RAM ו-40 GB של SSD עבור התקנה על צומת (node) יחיד בנפח קליטה נמוך. זהו רף תכנון בסיסי ולא מדידה מדויקת, לכן התייחסו אליו כאל גודל התחלתי ובדקו אותו מול התעבורה שלכם.
הזיכרון מתחלק לארבעה מקומות. ClickHouse בנוי למכונות עם זיכרון RAM רב וברירות המחדל שלו מניחות זאת. Postgres 16 צנוע יותר כאן, כיוון שהוא מחזיק מטא-דאטה ולא טלמטריה. גם ה-collector צנוע. ארבעת תהליכי ה-Node אינם כאלה: שרת פיתוח Vite בתוספת שלושה תהליכי tsx watch מחזיקים כל אחד מאות מגה-בייטים, וזו הסיבה ש-pnpm dev על מכונה עם 2 GB הוא חוויה קשה.
הדיסק הוא הבעיה השקטה יותר. pnpm install ב-monorepo הזה מושך את ה-AWS SDK, לקוח ClickHouse, את ה-OpenTelemetry SDK ושרשרת כלים של React עוד לפני שקלטתם span אחד. לאחר מכן, ClickHouse גדל בהתאם לתעבורה שלכם. מדדו את שניהם:
df -h /
free -m
docker stats --no-stream
docker compose exec clickhouse clickhouse-client --database superlog --query "SELECT table, formatReadableSize(sum(bytes_on_disk)) AS size FROM system.parts WHERE active AND database = 'superlog' GROUP BY table ORDER BY sum(bytes_on_disk) DESC"בנפח נמוך, כאשר קומץ שירותים שולחים כמה מאות spans בדקה, המכונה שקטה ו-ClickHouse נמצא ברובו במצב המתנה. העומס שגורם לבעיות הוא ה-burst: פריסה (deploy) אחת לא תקינה שמייצרת אלפי שגיאות זהות בדקה. תהליך ה-fingerprinting מאחד אותן לאירוע אחד עבור הקורא, אך ClickHouse עדיין כותב כל שורה ברקע.
הגדרת תקופת השמירה (retention) נתונה לבחירתכם. ה-ClickHouse exporter של ה-collector יוצר את הטבלאות, otel_traces, otel_logs וטבלה אחת לכל סוג מטריקה, והוא מחיל זמן תפוגה (TTL) רק אם ההגדרה ב-infra/collector/config.yaml קובעת זאת. דבר אינו פג תוקף מעצמו, לכן חודש עמוס יסתיים בדיסק מלא אלא אם תתכננו זאת מראש.
התקנה מגרסה ספציפית (pinned commit)
git clone https://github.com/superloglabs/superlog.git
cd superlog
git tag -l
git log -1 --format='%H %cs %s'git tag -l הצגת פלט ריק היא התוצאה הצפויה נכון לאוגוסט 2026. בחרו את ה-commit שבדקתם והישארו עליו:
git checkout 0d3a6c8bb63eda3493e6ba0003e7c2a70750bc1eכעת, שרשרת הכלים (toolchain):
node -v
corepack enable
corepack prepare pnpm@9.12.0 --activate
pnpm -vpackage.json מגדיר את engines.node כ->=20.0.0 ואת packageManager כ-pnpm@9.12.0. הרצת ההתקנה על גרסת Node ישנה תגרום ל-pnpm לעצור עם השגיאה ERR_PNPM_UNSUPPORTED_ENGINE, תוך ציון הגרסה הנדרשת. חבילת ה-nodejs במאגרים של Ubuntu 24.04 ישנה מגרסה 20, לכן יש להתקין Node 20 או חדש יותר מ-NodeSource או מ-nvm. המאגר כולל קובץ .nvmrc, לכן nvm use יבחר את הגרסה המיועדת אם מותקן אצלכם nvm.
pnpm install
docker compose up -d
docker compose psהמתינו לבדיקות התקינות (health checks) במקום להסתמך על up -d כאינדיקציה לכך שהשירות מוכן. Postgres ו-ClickHouse מגדירים בדיקה כזו בקובץ ה-compose:
curl -sS http://127.0.0.1:8123/ping
pg_isready -h 127.0.0.1 -p 5434 -U postgresClickHouse משיב Ok. ו-pg_isready משיב accepting connections. שגיאת Connection refused בפורט 8123 מעידה שהמכולה עדיין בתהליך עלייה או שקרסה. הפקודה docker compose logs clickhouse תציג מה המצב, ו-docker inspect $(docker compose ps -q clickhouse) | grep -i oomkilled תדווח על true אם ה-kernel הרג את התהליך עקב מחסור בזיכרון; זה מצביע על כך שהשרת קטן מדי ולא על בעיית תצורה.
לאחר מכן, בצעו את המיגרציה והפעילו את היישומים:
pnpm --filter @superlog/db db:migrate
pnpm devשימו לב לפורט: 5434, לא 5432. קובץ ה-compose מפרסם את Postgres בפורט 5434 כדי שלא יתנגש עם שרת Postgres שכבר מותקן על המארח, וקובצי ה-.env.example של היישום תואמים לכך באמצעות DATABASE_URL=postgres://postgres:postgres@localhost:5434/superlog. אם תפנו את המיגרציה לפורט 5432 בשרת שכבר מריץ Postgres, תקבלו שגיאת חיבור או, במקרה הגרוע, מיגרציה שתתבצע על מסד הנתונים הלא נכון.
pnpm dev מפעיל את ארבעת התהליכים המפורטים ב-Procfile של המאגר: api, web, worker ו-proxy. כל תהליך מנתב את הפלט שלו ל-tmp/logs/, לכן tail -f tmp/logs/proxy.log הוא המקום שבו יש לנטר את תהליך ה-ingest. ה-README מגדיר את יישום ה-web בפורט http://localhost:5173, את ה-API בפורט http://localhost:4100 ואת קליטת ה-OTLP בפורט http://localhost:4101.
וודאו מה באמת מאזין לפני שאתם מפנים אליו תעבורה:
ss -lntp | grep -E '4100|4101|5173'
curl -sS http://127.0.0.1:4101/healthזה חשוב להמשך. ה-proxy קורא את הפורט שלו ממשתנה הסביבה PORT וחוזר לפורט 4000 כאשר PORT אינו מוגדר. סביבת הפיתוח מגדירה זאת עבורכם. יחידת systemd שתכתבו בעצמכם לא תעשה זאת, ולכן exporter שמכוון ל-4101 מול proxy שמאזין ב-4000 ייכשל עם connection refused ללא רמז נוסף.
שליחת עקבה אחת, יצירת שגיאה אחת, צפייה בתקרית אחת
צרו פרויקט באפליקציית ה-web והעתיקו את מפתח ה-ingest שלו. ה-intake מאמת כל בקשה מול המפתח הזה, לכן טלמטריה שנשלחת ללא מפתח לעולם לא תגיע ל-ClickHouse.
כוונו כל OpenTelemetry SDK אל ה-intake באמצעות משתני הסביבה הסטנדרטיים:
export OTEL_SERVICE_NAME=checkout-api
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4101
export OTEL_EXPORTER_OTLP_HEADERS='x-api-key=YOUR_INGEST_KEY'ה-intake קורא את המפתח מה-header מסוג x-api-key, ומקבל גם את authorization: bearer YOUR_INGEST_KEY אם קל יותר להגדיר את ה-exporter שלכם בדרך זו. הוא משרת את שלושת נתיבי ה-OTLP הסטנדרטיים, /v1/traces, /v1/logs ו-/v1/metrics, בתוספת /health.
מלכודת אחת ראויה לציון. OTEL_EXPORTER_OTLP_ENDPOINT הוא base URL וה-SDK משרשר אליו את נתיב האות (signal path). משתנים ספציפיים לאותות כגון OTEL_EXPORTER_OTLP_TRACES_ENDPOINT משמשים בדיוק כפי שהם כתובים, ללא שרשור נתיב. הגדירו את המשתנה הספציפי לאות ל-http://127.0.0.1:4101 וכל ייצוא יישלח ל-/, שאינו נתיב תקין; כתוצאה מכך דבר לא יגיע וה-SDK יתעד כשל בייצוא בזמן שהאפליקציה שלכם נראית תקינה.
עבור שירות Node, נתיב ה-zero code מספיק כדי להוכיח את תקינות ה-pipeline:
npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node
node --require @opentelemetry/auto-instrumentations-node/register server.jsכעת גרמו לתקלה בכוונה. כל נתיב (route) שזורק שגיאה יתאים:
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/boomבדקו את הדילוגים (hops) לפי הסדר, כיוון שהפער הראשון יצביע על השלב שנכשל:
tail -n 50 tmp/logs/proxy.log
docker compose exec clickhouse clickhouse-client --database superlog --query 'SELECT count() FROM otel_traces'עלייה במונה ב-otel_traces כאשר אפליקציית ה-web ריקה מעידה על אי-התאמה של פרויקט, לכן בדקו לאיזה פרויקט שייך מפתח ה-ingest. מונה שטוח עם פעילות בלוג ה-proxy מצביע על ה-collector או על הכתיבה ל-ClickHouse, לכן קראו את docker compose logs collector. היעדר פעילות בלוג ה-proxy בכלל אומר שה-exporter מעולם לא הגיע ל-intake: פורט שגוי, נתיב שגוי, או מפתח שנדחה.
באפליקציית ה-web, כשלים חוזרים ונשנים אלו מגיעים כתקרית אחת במקום כשורה אחת לכל בקשה. Superlog מבצע fingerprinting לאותות נכנסים ומקבץ את התואמים שבהם, וזהו ההבדל בין תיבת דואר המכילה 4,000 שגיאות זהות לבין דף המכיל תקרית אחת. לאחר מכן, ה-agent כותב את החקירה שלו על גבי אותה קבוצה.
שלב החקירה קורא למודל, לכן ה-worker זקוק לספק מודל מוגדר. קחו את שמות המשתנים הללו מקובץ .env.example בתוך כל ספריית אפליקציה של ה-commit שקיבעתם (pinned), ולא מכל מדריך חיצוני, כיוון שהם משתנים בהתאם ל-main. אותו כלל חל על האינטגרציות של GitHub ו-Sentry, הנושאות את מסמכי ההגדרה שלהן ב-docs/github-app-setup.md ו-docs/sentry-app-setup.md, כאשר ה-webhook payloads מתועדים ב-docs/webhooks.md.
שמירה על פרטיות ה-intake והגבלת ה-agent לקריאה בלבד
Docker מפרסם פורטים של מכולות ב-0.0.0.0 כברירת מחדל. פורטים אלו עוקפים את ufw, כיוון ש-Docker כותב חוקים משלו לשרשרת DOCKER-USER, אשר נבדקים לפני ש-ufw רואה את החבילה. בשרת VPS עם כתובת IP ציבורית, קובץ ה-compose כפי שהוא מסופק חושף את ClickHouse HTTP בפורט 8123 ואת Postgres בפורט 5434 לגישה מהאינטרנט. פרטי ההתחברות בקובץ זה הם ברירות מחדל לפיתוח: משתמש ClickHouse הוא default ללא סיסמה, ו-Postgres משתמש ב-postgres גם כשם משתמש וגם כסיסמה.
יש לקשור אותם ל-loopback. כל פורט שמפורסם בקובץ ה-compose שואב את צד המארח שלו ממשתנה סביבה, לכן מספיק להגדיר .env בשורש המאגר:
POSTGRES_HOST_PORT=127.0.0.1:5434
CLICKHOUSE_HTTP_HOST_PORT=127.0.0.1:8123
CLICKHOUSE_TCP_HOST_PORT=127.0.0.1:9000
COLLECTOR_GRPC_HOST_PORT=127.0.0.1:4317
COLLECTOR_HTTP_HOST_PORT=127.0.0.1:4318אמתו את התוצאה לפני שתסתמכו עליה, ולאחר מכן צרו מחדש את המכולות:
docker compose config
docker compose up -d
ss -lntp | grep -E '5434|8123|9000|4317|4318'הפקודה docker compose config מדפיסה את הקובץ המפורש, כך שתוכלו לקרוא את 127.0.0.1:5434:5432 במקום לנחש. ss אמור להציג כעת 127.0.0.1:5434 ולעולם לא 0.0.0.0:5434. אל תנסו לתקן זאת באמצעות קובץ compose override שמגדיר מחדש את ports, כיוון ש-Compose משרשר רשימות פורטים בין קבצים במקום להחליף אותן; התוצאה תהיה ששתי ההגדרות יתקיימו והפורט הציבורי יישאר פתוח.
ה-intake דורש התייחסות דומה. מפתח ה-ingest שלכם עובר בתוך header, לכן הוא מחייב TLS (אבטחת שכבת תעבורה) לפניו: בצעו TLS termination ב-nginx או ב-Caddy לפני ה-proxy, או שמרו את ה-ingest בתוך רשת פרטית או מנהרת WireGuard. יישום ה-web בפורט 5173 הוא שרת פיתוח של Vite ואין לו שום סיבה להיחשף לאינטרנט.
לאחר מכן, ה-agent עצמו. הערך המוסף של Superlog הוא שה-agent חוקר ומציע תיקון, והמילה החשובה כאן היא "מציע". שמרו אותו במצב קריאה בלבד (read only) מול סביבת ה-production עד שתראו אותו פועל בכמה אירועים אמיתיים. העניקו ל-GitHub App הרשאות קריאה ואפשרו לו לפתוח pull requests שאתם תבחנו. agent שקורא טלמטריה וכותב תיקון הוא כלי מועיל. agent שיכול להפעיל מחדש את השירותים שלכם מייצג רמת סיכון שונה, והחלטה כזו צריכה להתקבל במכוון ולא כברירת מחדל שירשתם. עלויות דורשות תשומת לב דומה, שכן כל חקירה היא קריאה למודל: הגדירו תקציב להוצאות ה-agent ב-VPS לפני שתכוונו אותו למערכת production רועשת, ושמרו תיעוד של הפעולות שביצע ה-agent כדי שלכל pull request מפתיע יהיה נתיב ביקורת (audit trail) מאחוריו.
כשלים נפוצים והמחרוזות המזהות אותם
ERR_PNPM_UNSUPPORTED_ENGINEבמהלךpnpm installמציין שגרסת Node ישנה מ-20. הפקודהnode -vמאשרת זאת בשורה אחת.ECONNREFUSED 127.0.0.1:5434במהלך המיגרציה מציין ש-compose stack אינו פעיל, או ש-DATABASE_URLמציין פורט שגוי.- אתחול חוזר ונשנה של ClickHouse נובע בדרך כלל ממחסור בזיכרון. קראו את
docker compose logs clickhouse, ולאחר מכן בדקו אם בתוך המכולהOOMKilledמוגדר כ-true. - Exporter שמדווח על הצלחה בעוד אפליקציית ה-web נשארת ריקה, משמעו שהנתונים עברו ישירות ל-collector בפורט 4318, מה שעוקף את תיוג הפרויקט שמבצע ה-proxy.
- השגיאה Connection refused בפורט 4101 בהתקנת production מציינת שה-proxy חזר להשתמש ב-
PORT=4000. הגדירו אתPORTבמפורש בקובץ ה-unit. docker compose psהמציג0.0.0.0:8123מציין שקישורי ה-loopback אינם פעילים. הריצו אתdocker compose configובדקו את הפורטים המזוהים.
Flawless, HyperProbe ומיקומו של Superlog
קטגוריה זו היא צעירה, והכלים נחלקים לפי מה שמותר לסוכן (agent) לבצע. Flawless הוא כלי AI SRE (הנדסת אמינות אתרים) בקוד פתוח המיועד ל-Kubernetes, והוא קורא נתונים מ-stack קיים של Prometheus, Loki ו-Grafana במקום להחזיק בצינור הנתונים (pipeline) בעצמו. HyperProbe פועל בכיוון ההפוך: זהו מוצר מנוהל (hosted), שקוד המקור שלו סגור נכון לאוגוסט 2026, המציב בדיקות (probes) לקריאה בלבד בתוך תהליך רץ כדי ללכוד מצב משתנים, וחושף מצב זה לעוזר חכם באמצעות MCP (פרוטוקול הקשר למודל).
Superlog ממוקם בין השניים. הוא מחזיק בצינור הנתונים מקצה לקצה, החל מקליטת OTLP ועד לאחסון ב-ClickHouse, והוא מציב את הסוכן בשלב המיון (triage) ולא בשלב התיקון. תכנון זה הוא בדיוק הסיבה לכך שאירוח עצמי שלו הוא החלטת תשתית ולא סתם מכולה (container) שאפשר לשכוח ממנה. ברגע שמריצים את Superlog, מריצים מסד נתונים טורי (column store), והוא דורש את אותה רמת טיפול כמו כל מסד נתונים אחר שבבעלותכם.
FAQ
כמה זיכרון RAM דרוש ל-Superlog באירוח עצמי?
תכננו עבור 8 GB של RAM, 4 vCPU ו-40 GB של שטח דיסק עבור צומת יחיד בנפח קליטה נמוך. ה-stack מורכב מ-Postgres, ClickHouse, אוסף OpenTelemetry וארבעה תהליכי Node, כאשר ClickHouse דורש מרווח נשימה. שרת VPS עם 1 GB או 2 GB אינו מספיק: pnpm install כשלעצמו כבד, ו-ClickHouse יופסק על ידי ה-kernel באמצעות ה-out of memory killer תחת עומס. מדדו את הנתונים שלכם בעזרת docker stats --no-stream ו-free -m במקום להסתמך על נתונים מפורסמים, כולל אלו.
לאיזה פורט עליי להפנות את ה-OTLP exporter שלי?
ל-proxy הקליטה של Superlog, אשר ה-README מציב ב-http://localhost:4101. הוא משרת את /v1/traces, /v1/logs ו-/v1/metrics, ומבצע אימות מול מפתח הקליטה של הפרויקט שלכם שנלקח מה-header x-api-key או מ-header authorization: bearer. פורט 4318 הוא ה-OpenTelemetry collector שמתחתיו, וייצוא ישיר אליו עוקף את ה-proxy, שהוא הרכיב שמטביע את מזהה הפרויקט שלכם על הנתונים. ה-proxy חוזר לפורט 4000 כאשר PORT אינו מוגדר, לכן הריצו את ss -lntp ואמתו למה הוא חובר לפני שתניחו שמדובר ב-4101.
האם Superlog מחליף את Uptime Kuma או Zabbix?
לא. Uptime Kuma עונה על השאלה האם נקודת קצה מגיבה מחוץ לרשת שלכם, ו-Zabbix מנטר מדדי מארח ושירות מול ספים שהגדרתם. Superlog צורך את ה-traces, הלוגים והמדדים שהיישומים שלכם פולטים ומקבץ כשלים חוזרים לאירועים. שמרו על בדיקת uptime חיצונית לצדו, כיוון שבדיקה שרצה במקום אחר תדווח גם כאשר השרת שמחזיק את תשתית הטלמטריה שלכם הוא זה שקרס.
האם ה-agent של Superlog יכול לשנות את מערכות ה-production שלי?
רק באמצעות הרשאות שאתם מעניקים לו. הפלט שלו הוא חקירה ושינוי מוצע שבן אדם בוחן. שמרו את ה-GitHub App על הרשאות קריאה בלבד עם pull requests בהתחלה, ושמרו על כל אישורי הגישה שה-worker מחזיק מוגבלים לקריאה בלבד. התייחסו לגישת כתיבה ל-production כאל החלטה נפרדת שמתקבלת במכוון, כיוון ש-agent שיכול להפעיל מחדש שירותים הוא מחויבות גדולה בהרבה מ-agent שקורא טלמטריה וכותב תיקון לבחינה.
האם עליי לקבע commit או לעקוב אחרי main?
קבעו commit. אין תגיות release במאגר נכון לאוגוסט 2026, לכן main הוא היעד המשתנה היחיד שמוצע והוא כולל כמה commits בשבוע. תעדו את ה-SHA שבדקתם, בצעו deploy לזה, וקראו את ה-diff לפני שתתקדמו. git log --oneline <old-sha>..main הוא הבחינה, וקובצי ה-.env.example לכל יישום הם המקום הראשון לחפש בו משתנים שנדרשים לאחר כל עדכון.