Ilia Denisov
bb71e7b1c7
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 12s
CI / integration (pull_request) Successful in 26s
CI / ui (pull_request) Successful in 1m11s
CI / conformance (pull_request) Successful in 10s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m56s
The bot runs on its own host and exports no telemetry (otelcol is unreachable
from there), so it was a monitoring blind spot. Observe its Bot API health
centrally by wrapping the HTTP client — one place, no per-call-site
instrumentation — and relay it up the existing bot-link as a periodic Health
message the gateway turns into its own metrics.
- proto: add Health (delta connect / api / 429 counters + a last-ok stamp) to
the FromBot oneof (additive, backward-compatible).
- bot: platform/telegram/internal/health wraps the Bot API HTTP client — it
stamps liveness on any 2xx (so the getUpdates long-poll keeps it fresh even
when idle), classifies transport/5xx failures (getUpdates vs other) and 429s,
and honours a 429's Retry-After (bounded) so the bot backs off; a 4xx other
than 429 is a normal per-request outcome and is not counted.
- bot-link client: flush the reporter as a Health message every 30s over a
single-sender loop (a gRPC stream forbids concurrent Send).
- gateway: fold each report into bot_tg_errors_total{kind} and the
bot_tg_last_ok_unix liveness gauge.
- grafana: alerts (bot disconnected, bot not reaching the Bot API, sustained
429s) routed to the operator email — which does not go through the bot — plus
a Telegram-bot dashboard.
- docs (ARCHITECTURE, compose comments); unit tests (observer classification,
Retry-After, snapshot/commit, hub last-ok monotonicity).
72 lines
3.4 KiB
YAML
72 lines
3.4 KiB
YAML
# Production Telegram bot host descriptor (standalone — NOT an overlay). Run only on
|
|
# the bot host:
|
|
# docker compose -f docker-compose.bot.yml up -d
|
|
#
|
|
# The bot egresses to the Bot API directly (no VPN sidecar) and dials the main host's
|
|
# published bot-link :9443 over mTLS. It exports no OTLP telemetry — otelcol lives on the
|
|
# main host and is unreachable from here — but it reports its Bot API health up the bot-link,
|
|
# which the gateway turns into metrics + alerts on the main host (docs/ARCHITECTURE.md); `docker
|
|
# logs` on this host is the local detail view.
|
|
# Values come from the prod-deploy workflow (PROD_ secrets/variables); BOT_IMAGE is the
|
|
# pushed registry tag and BOTLINK_GATEWAY_ADDR is the main host's <ip>:9443.
|
|
name: scrabble-bot
|
|
|
|
services:
|
|
bot:
|
|
container_name: scrabble-telegram-bot
|
|
image: ${BOT_IMAGE:?set BOT_IMAGE to the registry tag}
|
|
restart: unless-stopped
|
|
logging:
|
|
driver: json-file
|
|
options:
|
|
max-size: "10m"
|
|
max-file: "3"
|
|
environment:
|
|
TELEGRAM_BOT_TOKEN: ${TELEGRAM_BOT_TOKEN:?set TELEGRAM_BOT_TOKEN}
|
|
TELEGRAM_GAME_CHANNEL_ID: ${TELEGRAM_GAME_CHANNEL_ID:-}
|
|
TELEGRAM_CHAT_ID: ${TELEGRAM_CHAT_ID:-}
|
|
# Support relay: a private forum supergroup the bot relays direct user messages
|
|
# into (one topic per user). 0/unset disables it; the bot needs admin there with
|
|
# the manage-topics and delete-messages rights.
|
|
TELEGRAM_SUPPORT_CHAT_ID: ${TELEGRAM_SUPPORT_CHAT_ID:-}
|
|
TELEGRAM_SUPPORT_STATE_DIR: /data
|
|
# The Telegram Stars payment outbox (shares the bot-state volume). A writable dir enables the
|
|
# Stars rail; empty disables it. The rail stays inert until a chip pack carries an XTR (Stars)
|
|
# price, so it is safe to leave on — seeding a Stars price in the admin is the real go-live.
|
|
TELEGRAM_STARS_OUTBOX_DIR: ${TELEGRAM_STARS_OUTBOX_DIR:-/data}
|
|
TELEGRAM_PROMO_BOT_TOKEN: ${TELEGRAM_PROMO_BOT_TOKEN:-}
|
|
TELEGRAM_BOT_USERNAME: ${TELEGRAM_BOT_USERNAME:-}
|
|
TELEGRAM_BOT_LINK: ${TELEGRAM_BOT_LINK:-}
|
|
TELEGRAM_PROMO_START_PARAM: ${TELEGRAM_PROMO_START_PARAM:-}
|
|
TELEGRAM_MINIAPP_URL: ${TELEGRAM_MINIAPP_URL:?set TELEGRAM_MINIAPP_URL}
|
|
# Real Bot API in prod (the test contour pins TELEGRAM_TEST_ENV=true instead).
|
|
TELEGRAM_TEST_ENV: "false"
|
|
TELEGRAM_API_BASE_URL: ${TELEGRAM_API_BASE_URL:-}
|
|
TELEGRAM_OWNS_UPDATES: "true"
|
|
# Dials the main host's published bot-link. ServerName stays `gateway` (the cert
|
|
# SAN), so TLS validation is independent of the dial address.
|
|
TELEGRAM_GATEWAY_ADDR: ${BOTLINK_GATEWAY_ADDR:?set BOTLINK_GATEWAY_ADDR (main:9443)}
|
|
TELEGRAM_BOTLINK_SERVER_NAME: gateway
|
|
TELEGRAM_BOTLINK_TLS_CERT: /certs/bot.crt
|
|
TELEGRAM_BOTLINK_TLS_KEY: /certs/bot.key
|
|
TELEGRAM_BOTLINK_TLS_CA: /certs/ca.crt
|
|
TELEGRAM_LOG_LEVEL: ${LOG_LEVEL:-info}
|
|
TELEGRAM_SERVICE_NAME: scrabble-telegram-bot
|
|
# No OTLP export: otelcol is on the main host, unreachable from here. Bot API health rides the
|
|
# bot-link instead (the gateway exposes it as metrics); see docs/ARCHITECTURE.md.
|
|
TELEGRAM_OTEL_TRACES_EXPORTER: none
|
|
TELEGRAM_OTEL_METRICS_EXPORTER: none
|
|
GOMAXPROCS: "1"
|
|
volumes:
|
|
- ${SCRABBLE_CONFIG_DIR:-.}/certs:/certs:ro
|
|
# Support relay state (topic mapping, block list); survives redeploys.
|
|
- bot-state:/data
|
|
deploy:
|
|
resources:
|
|
limits:
|
|
cpus: "1.0"
|
|
memory: 256M
|
|
|
|
volumes:
|
|
bot-state:
|