Appearance

Best practices ​

Production-ready patterns for Amlexia instrumentation.

SDK key hygiene ​

  • Store AMLEXIA_SDK_KEY in server env or a secrets manager — never in git, never in the browser.
  • Use separate projects for staging and production so test traffic does not skew alerts.
  • Rotate keys from the dashboard if a key is exposed.

Shutdown and deploys ​

Always flush on process exit so the last batch is not lost:

typescript
process.on('SIGTERM', async () => {
  await client.shutdown();
  process.exit(0);
});
python
import atexit
atexit.register(client.shutdown)

On serverless (short-lived workers), call flush() after each invocation if you cannot rely on shutdown().

Route naming ​

  • Prefer middleware so paths are normalized (/users/:id not /users/42).
  • For outbound calls, use a clear endpoint label: POST openai/chat or the real path.
  • Background jobs: track() with a stable name like cron/sync-inventory.

Metadata ​

  • Do not log passwords, API keys, full request bodies, or raw emails in metadata.
  • Prefer ids and enums: plan: "pro", feature: "checkout".

Alerts ​

  1. Start with error rate and p95 latency on your top 3 routes.
  2. Add cost alerts if you run heavy LLM traffic.
  3. Use a staging project to validate thresholds before paging production.

Staging vs production ​

PracticeWhy
Different SDK keys per environmentClean separation in dashboard
Set AMLEXIA_ENVIRONMENTFilter and compare in traces
Set AMLEXIA_RELEASE to git SHATie incidents to deploys

Performance ​

  • Default batching (5s / 50 events) is safe for most APIs.
  • High-throughput services: lower flushIntervalMs only if you need faster Live view — more HTTP calls to ingest.
  • SDK retries handle transient 429/5xx; fix sustained 429 by reducing volume or contacting support.