diff --git a/apps/landing/messages/en.json b/apps/landing/messages/en.json index e805be3a66..07d506d8b7 100644 --- a/apps/landing/messages/en.json +++ b/apps/landing/messages/en.json @@ -452,7 +452,8 @@ "faq_home_agents_a": "Yes. Maple runs an MCP (Model Context Protocol) server, so compatible AI agents can list services, search traces, find errors, and propose fixes directly against your telemetry.", "hero_announce_badge": "New", - "hero_announce_text": "Maple Local: one binary, no account.", + "hero_announce_text": "On-call in Maple: schedules, escalation and silences.", + "hero_announce_href": "/changelog/2026-11-07-on-call", "signals_eyebrow": "01 · Signals", "signals_trace_title": "Read the trace.", diff --git a/apps/landing/messages/ja.json b/apps/landing/messages/ja.json index 788d65815b..23c764f2dd 100644 --- a/apps/landing/messages/ja.json +++ b/apps/landing/messages/ja.json @@ -441,7 +441,8 @@ "faq_home_agents_a": "はい。MapleはMCP（Model Context Protocol）サーバーを備えています。対応するAIエージェントは、サービス一覧の取得、トレース検索、エラーの特定、修正案の提示を、テレメトリに対して直接実行できます。", "hero_announce_badge": "\u65b0\u7740", - "hero_announce_text": "Maple Local：ひとつのバイナリ、アカウント不要。", + "hero_announce_text": "Maple でオンコール：スケジュール、エスカレーション、サイレンス。", + "hero_announce_href": "/changelog/2026-11-07-on-call", "signals_eyebrow": "01 · シグナル", "signals_trace_title": "\u30c8\u30ec\u30fc\u30b9\u3092\u8aad\u3080\u3002", diff --git a/apps/landing/messages/ko.json b/apps/landing/messages/ko.json index a7036f6c17..f11d1b7ebf 100644 --- a/apps/landing/messages/ko.json +++ b/apps/landing/messages/ko.json @@ -441,7 +441,8 @@ "faq_home_agents_a": "네. Maple은 MCP(Model Context Protocol) 서버를 실행합니다. 호환되는 AI 에이전트는 서비스 목록 조회, 트레이스 검색, 오류 탐색, 수정 제안을 텔레메트리에 직접 수행할 수 있습니다.", "hero_announce_badge": "\uc2e0\uaddc", - "hero_announce_text": "Maple Local: 바이너리 하나, 계정 불필요.", + "hero_announce_text": "Maple 온콜: 스케줄, 에스컬레이션, 사일런스.", + "hero_announce_href": "/changelog/2026-11-07-on-call", "signals_eyebrow": "01 · 시그널", "signals_trace_title": "\ud2b8\ub808\uc774\uc2a4\ub97c \uc77d\uc73c\uc138\uc694.", diff --git a/apps/landing/src/components/home/HomeHero.astro b/apps/landing/src/components/home/HomeHero.astro index 9ad4ffcc0f..70ad37f971 100644 --- a/apps/landing/src/components/home/HomeHero.astro +++ b/apps/landing/src/components/home/HomeHero.astro @@ -18,19 +18,19 @@ import { DATA_POINTS_INGESTED, formatDataPoints } from "../../lib/ingest-stats"; import { getGitHubStars, formatStars } from "../../lib/github-stars"; const stars = await getGitHubStars(); -const locale = Astro.currentLocale ?? "en"; -const localPath = locale === "en" ? "/local" : `/${locale}/local`; +// The changelog is English only, so the link is the same in every locale. +const announceHref = m.hero_announce_href(); ---
{m.hero_announce_badge()} {m.hero_announce_text()} diff --git a/apps/landing/src/content/changelog/2026-10-19-google-cloud.md b/apps/landing/src/content/changelog/2026-10-19-google-cloud.md new file mode 100644 index 0000000000..6214a11c09 --- /dev/null +++ b/apps/landing/src/content/changelog/2026-10-19-google-cloud.md @@ -0,0 +1,26 @@ +--- +title: "Connect Google Cloud" +description: "Bring Cloud Logging, Cloud Monitoring metrics and your Google Cloud resources into Maple, set up by script, console steps or Terraform." +date: 2026-10-19 +category: integrations +authors: [jeremyfunk, makisuo] +--- + +You can now connect a Google Cloud **organization, folder or project** to Maple. Each connection +collects what you choose: + +- **Log forwarding.** Cloud Logging entries arrive in **Logs** under the service that wrote them. +- **Metrics and resources.** Metrics for Cloud Run, Cloud Functions, GKE, Compute Engine, Cloud + SQL, Pub/Sub and HTTP(S) load balancers every 5 minutes, and the resources behind them every + hour. They are named `gcp.*` and work in dashboards and alert rules. + +**Infrastructure → Google Cloud** shows a health band across every workload (saturated, elevated, +erroring), a table per service type, and a page per workload with its charts. The workloads also +appear on the Infrastructure overview and the service map, and a dashboard template gets you a +starting point. + +Pick how to set it up in the connect dialog: a Cloud Shell script, console steps with your +connection's values ready to copy, or a Terraform or Alchemy file. The IaC option also comes as a +prompt you can hand to a coding agent. + +Get started with the [Google Cloud guide](/docs/integrations/gcp). diff --git a/apps/landing/src/content/changelog/2026-10-23-aws-cloudwatch.md b/apps/landing/src/content/changelog/2026-10-23-aws-cloudwatch.md new file mode 100644 index 0000000000..8407162c8d --- /dev/null +++ b/apps/landing/src/content/changelog/2026-10-23-aws-cloudwatch.md @@ -0,0 +1,24 @@ +--- +title: "Connect AWS and stream CloudWatch metrics" +description: "Connect an AWS account with a read-only role and no stored secret, stream CloudWatch metrics, and see every resource under Infrastructure → AWS." +date: 2026-10-23 +category: integrations +authors: [makisuo] +--- + +You can now connect an **AWS account** to Maple. The setup creates a read-only IAM role in your +account, deployed as a CloudFormation stack from CloudShell, in the console, or with Terraform. +Maple assumes it with short-lived tokens it signs for your connection, so there is no access key +to create, store or rotate. + +A connection can also **stream CloudWatch metrics** to Maple. Pick the regions and the services +(ECS, Container Insights, ALB, NLB, RDS, Lambda, SQS, EC2, DynamoDB, API Gateway) and AWS pushes +the metrics as they are published. Maple reads nothing back from the account. + +Once metrics arrive, **Infrastructure → AWS** lists each resource by kind: ECS services, EC2 +instances, load balancers, RDS, Lambda and SQS. A health band calls out what is hot, erroring, +throttled, backed up, or idle and still billed, and filters the table to it. Each resource has a +page with its metrics, a link to the AWS console and, for ECS services and Lambda functions, the +traced service it runs as with its calls, errors and p95. + +Get started with the [AWS guide](/docs/integrations/aws). diff --git a/apps/landing/src/content/changelog/2026-10-24-service-api-tab.md b/apps/landing/src/content/changelog/2026-10-24-service-api-tab.md new file mode 100644 index 0000000000..b6e3ecc03c --- /dev/null +++ b/apps/landing/src/content/changelog/2026-10-24-service-api-tab.md @@ -0,0 +1,21 @@ +--- +title: "A rebuilt API tab on service pages" +description: "See what an HTTP service rejects and why, what is slow, who calls it and how big the requests are." +date: 2026-10-24 +category: services +authors: [makisuo] +--- + +The **API** tab on a service page now answers what operators of an HTTP service ask first. + +- **A KPI strip**: requests per second, the 4xx share with its leading status code ("mostly 402"), + the 5xx share, p95 against the previous window of the same length, and request bytes per second + with the average body size. Each has a sparkline. +- **Responses by status**: 2xx, 4xx and 5xx stacked over the window, with deploy markers. +- **Non-2xx responses**: each status code with its count, share, most common error type and the + routes that returned it. +- **An endpoint table** with filters for routes rejecting more than 5% of requests or slower than + 100 ms at p95. +- **An endpoint drawer**: click a route to see its status codes, latency distribution, top + clients, request body sizes and slowest requests, each linking to its trace. The URL keeps the + open endpoint, so you can share it. diff --git a/apps/landing/src/content/changelog/2026-10-25-onboarding.md b/apps/landing/src/content/changelog/2026-10-25-onboarding.md new file mode 100644 index 0000000000..7902076637 --- /dev/null +++ b/apps/landing/src/content/changelog/2026-10-25-onboarding.md @@ -0,0 +1,24 @@ +--- +title: "A new onboarding, and one connect flow for every source" +description: "Onboarding asks what you run, connects it in place and ends on your own first data. Every source now connects through the same four steps." +date: 2026-10-25 +category: platform +authors: [makisuo] +--- + +Setting up a new organization is shorter and ends somewhere useful: + +1. **Plan.** Choose a plan, or skip it if your organization already has one. +2. **Stack.** Pick your languages and where they run. Every language we document is listed, with + search. The page shows which parts of Maple those picks fill in. +3. **Connect.** Set up what you picked. Each provider opens in a drawer, so you never lose your + place. +4. **Team.** Invite people and bring in GitHub, Slack and your editor. +5. **You're live.** See whether data is flowing, and start from your own data: the service map, + your slowest service and your errors from the last 24 hours. Anything you picked but haven't + connected yet is listed with its setup link. + +Adding a source later works the same way everywhere. **Sources → New** walks every integration +through **Source, Connect, Choose data, Go live**. A status line says what Maple is waiting for or +what it found, so there is no separate test button, and the side rail says what Maple reads before +you grant it. diff --git a/apps/landing/src/content/changelog/2026-10-26-uptime-monitoring.md b/apps/landing/src/content/changelog/2026-10-26-uptime-monitoring.md new file mode 100644 index 0000000000..50e1803163 --- /dev/null +++ b/apps/landing/src/content/changelog/2026-10-26-uptime-monitoring.md @@ -0,0 +1,28 @@ +--- +title: "Uptime monitoring" +description: "Hosted HTTP, TCP, DNS and heartbeat checks that open incidents through your alert routing and link each failed check to its trace." +date: 2026-10-26 +category: alerts +authors: [makisuo] +--- + +Maple now runs **uptime checks** for you. Add a monitor from **Alerts → Uptime**, or pick +**Uptime check** from **New rule**: + +- **HTTP**: status code, response time, body text, JSON path and header assertions. +- **TCP**: the port accepts a connection. +- **DNS**: the name resolves, optionally to the record you expect. +- **Heartbeat**: your cron job or worker pings a URL on an interval or a cron schedule, and Maple + alerts when a ping is late or reports a failure. + +Checks run every 30 seconds to every hour. A monitor goes down after 1 to 10 failed checks in a +row (2 by default) and comes back up on the first success. A down monitor opens an incident +through the same routing as your alert rules, and the notification reads "checkout-api is down" +with the check's error. + +Each HTTP check sends a `traceparent` header, so a failed check links to the trace your service +recorded for it. The monitor page charts response time split into DNS, connect, TLS, time to +first byte and transfer, so you can see which phase got slow. Link a monitor to a service and it +shows on the service page, and counts toward that service's health. + +Read more on the [uptime monitoring page](/features/uptime-monitoring). diff --git a/apps/landing/src/content/changelog/2026-10-28-ingest-rules.md b/apps/landing/src/content/changelog/2026-10-28-ingest-rules.md new file mode 100644 index 0000000000..dfae31f6f4 --- /dev/null +++ b/apps/landing/src/content/changelog/2026-10-28-ingest-rules.md @@ -0,0 +1,24 @@ +--- +title: "Ingest rules: drop and redact data before it is stored" +description: "Drop noisy logs, spans and metrics, or redact personal data and secrets, before Maple stores or bills them." +date: 2026-10-28 +category: platform +authors: [makisuo] +--- + +You can now write **ingest rules** that run on your telemetry as it arrives, before it is stored +or counted toward your bill. + +- **Drop** logs, spans or metrics you don't need: health checks, debug logs from one service, a + chatty metric. You can drop all of them or keep a percentage. +- **Redact** values in place, such as email addresses, tokens or card numbers in log bodies and + attributes. + +Find them under **Settings → Ingestion → Ingest rules**. The editor reads as a sentence (when, +where, then) and has a **live preview**: it runs the rule against your 100 newest logs or spans +from the last hour and shows what would be dropped and each value before and after redaction. +The empty state offers templates to start from. + +Each rule shows its hits over the last 24 hours. **Billing & usage** shows how much data rules +dropped in the current cycle, which is not billed. Rules are also available through the +`/v2/ingest_rules` API. diff --git a/apps/landing/src/content/changelog/2026-10-28-terraform-provider.md b/apps/landing/src/content/changelog/2026-10-28-terraform-provider.md new file mode 100644 index 0000000000..bc147cef9b --- /dev/null +++ b/apps/landing/src/content/changelog/2026-10-28-terraform-provider.md @@ -0,0 +1,23 @@ +--- +title: "A Terraform provider for Maple" +description: "Manage dashboards, alert rules, destinations, uptime monitors, scrape targets and API keys in Terraform." +date: 2026-10-28 +category: api +authors: [makisuo] +--- + +Maple now has a **Terraform provider**, `mapletechlabs/maple`. Declare your Maple configuration +next to the infrastructure it watches, and review every change in a plan first: + +- `maple_dashboard` +- `maple_alert_rule` and `maple_alert_destination` +- `maple_uptime_monitor` +- `maple_scrape_target` +- `maple_api_key`, plus a `maple_ingest_keys` data source + +Existing resources can be imported, so you can bring what you built in the dashboard under Terraform +without recreating it. The provider uses the public v2 API with an API key from +**Settings → Keys**. + +Get started with the [Terraform guide](/docs/iac/terraform) and the +[resource reference](/docs/iac/terraform-resources). diff --git a/apps/landing/src/content/changelog/2026-10-30-otlp-grpc.md b/apps/landing/src/content/changelog/2026-10-30-otlp-grpc.md new file mode 100644 index 0000000000..dad069c5bd --- /dev/null +++ b/apps/landing/src/content/changelog/2026-10-30-otlp-grpc.md @@ -0,0 +1,22 @@ +--- +title: "Send telemetry over OTLP/gRPC" +description: "The ingest endpoint now accepts OTLP over gRPC as well as HTTP, so exporters that default to gRPC work without a protocol change." +date: 2026-10-30 +category: platform +authors: [makisuo] +--- + +Maple's ingest endpoint now accepts **OTLP over gRPC**, on the same host and port as OTLP over +HTTP. Java, .NET, Python and the OpenTelemetry Collector often default to gRPC, and they can now +send traces, logs and metrics to Maple as they are configured: + +```bash +export OTEL_EXPORTER_OTLP_ENDPOINT="https://ingest.maple.dev" # https://ingest.eu.maple.dev for EU organizations +export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer YOUR_INGEST_KEY" +export OTEL_EXPORTER_OTLP_PROTOCOL="grpc" +``` + +gzip compression, request limits and ingest keys work the same as over HTTP. Errors come back as +gRPC status codes, and the ones worth retrying are `UNAVAILABLE`, which exporters already retry. + +See the [Ingest API reference](/docs/reference/ingest#grpc). diff --git a/apps/landing/src/content/changelog/2026-11-01-mcp-servers.md b/apps/landing/src/content/changelog/2026-11-01-mcp-servers.md new file mode 100644 index 0000000000..64653dfa1d --- /dev/null +++ b/apps/landing/src/content/changelog/2026-11-01-mcp-servers.md @@ -0,0 +1,28 @@ +--- +title: "See how agents use your MCP server" +description: "A new MCP servers page shows the tools agents call, the clients calling them, why calls fail, and each session and user, from the spans your server already sends." +date: 2026-11-01 +category: ai +authors: [makisuo] +--- + +If you run an **MCP server**, **Explore → MCP servers** now shows how agents use it. Maple reads +the spans your server already emits under the OpenTelemetry MCP conventions. There is no extra SDK +or second call to make. + +- **The list** has every service that answers MCP tool calls, with calls, failure rate, p95, + tool count, top client and a volume sparkline. +- **A server's page** charts calls, failures, latency and clients, and breaks them down by tool, + client (Claude, Cursor and so on), failure kind and MCP method. +- **A tool's page** groups its errors by type and message, and lists the slowest, failed and + recent calls, each linking to its trace. +- **Sessions** group a server's requests by MCP session, in order, linked to the agent session + that made them and to the user behind it. + +A server that doesn't send what a view needs gets a checklist of the attributes to add, not an +empty table. + +Connecting your own agent to Maple is also quicker: the **Connect** panel in the top bar has a +copy-paste command for Claude Code and one-click install links for Cursor and VS Code. + +Read more in [MCP servers](/docs/mcp-servers/overview). diff --git a/apps/landing/src/content/changelog/2026-11-03-error-grouping.md b/apps/landing/src/content/changelog/2026-11-03-error-grouping.md new file mode 100644 index 0000000000..79d5c0d6de --- /dev/null +++ b/apps/landing/src/content/changelog/2026-11-03-error-grouping.md @@ -0,0 +1,23 @@ +--- +title: "Merge duplicate issues and set error grouping yourself" +description: "Merge error issues that are the same bug, split them back out, and name a grouping key in code when the automatic grouping gets it wrong." +date: 2026-11-03 +category: errors +authors: [makisuo] +--- + +Three changes to how errors become issues: + +- **Merge issues.** Select issues on the **Errors** page and choose **Merge**, then pick the one + to keep. Its count and builds include the others, and their future occurrences land on it. A + merged issue's page links to where it went and has **Unmerge**, which hands back exactly the + occurrences it brought. Merging is also available from the API and MCP. +- **Set the grouping in code.** Put a `maple.fingerprint` attribute on an error span or its + exception event, and every error in that service with the same value becomes one issue, + whatever its stack or message. Use a fixed name for the failure, never a per-request value. +- **Grouping by your own code.** When a stack has frames from your application, frames from + dependencies and the runtime no longer affect the grouping. An error thrown inside a library now + groups by the code of yours that called it. Existing issues carried over to the new grouping + with their state, history and counts. + +See [How errors are grouped](/docs/errors/overview#how-errors-are-grouped). diff --git a/apps/landing/src/content/changelog/2026-11-06-alert-destinations.md b/apps/landing/src/content/changelog/2026-11-06-alert-destinations.md new file mode 100644 index 0000000000..36a567aaa0 --- /dev/null +++ b/apps/landing/src/content/changelog/2026-11-06-alert-destinations.md @@ -0,0 +1,26 @@ +--- +title: "Send alerts to Microsoft Teams, Google Chat, incident.io and Linear" +description: "Four new alert destinations, plus Discord for every organization and the Maple bot in Hazel." +date: 2026-11-06 +category: alerts +authors: [makisuo] +--- + +Alert rules can now notify more of the tools your team already works in: + +- **Microsoft Teams.** Alerts post to a channel through a Workflows webhook, as a card with the + state, severity, group, chart and **Open in Maple** and **Ask Maple AI** buttons. +- **Google Chat.** Alerts post to a space as a card with the chart. A resolve or reminder replies + in the thread its trigger started. +- **incident.io.** Maple raises an alert on an HTTP alert source and resolves it when the incident + clears. The rule, severity, value and group come along as metadata your routes can match on. +- **Linear.** Instead of a message, Maple keeps one issue per rule and group in the team you pick. + A repeat fire comments on it, a resolve comments and leaves it open for your team to close, and + a fire within 24 hours of closing reopens it. Add Linear to a rule's critical tier only to + ticket just the serious incidents. + +The **Discord** integration is now open to every organization, and the Maple bot is available in +**Hazel**. In both, alerts post to a channel and you can ask Maple questions in a thread. + +Every destination has a **Send test** button. Set them up from the **Routing** tab in Alerts, and +see [Notification destinations](/docs/alerting/notification-destinations) for each one. diff --git a/apps/landing/src/content/changelog/2026-11-06-metrics-group-by.md b/apps/landing/src/content/changelog/2026-11-06-metrics-group-by.md new file mode 100644 index 0000000000..c4b6d32bd3 --- /dev/null +++ b/apps/landing/src/content/changelog/2026-11-06-metrics-group-by.md @@ -0,0 +1,24 @@ +--- +title: "Group metrics by several labels at once" +description: "The metrics builder now aggregates within each series and then across series, grouped by up to five fields." +date: 2026-11-06 +category: dashboards +authors: [makisuo] +--- + +The metrics query builder now aggregates in two steps, the way metrics are usually read: + +1. **Within each time series**: `avg`, `sum`, `min`, `max`, `count`, `latest`, `rate` or + `increase` over each interval. +2. **Across time series**: `sum`, `avg`, `min`, `max` or `count`, grouped by up to five fields + at once, mixing `service.name`, metric attributes and resource attributes. + +So "memory summed over pods, by namespace and job" or "requests per second by namespace and host" +is now one builder query instead of SQL. + +This also fixes grouped metric charts: + +- Series that report more often no longer weigh more in an average. +- A grouped line no longer jumps between services' values from one bucket to the next. +- A `rate` in a widget no longer comes out 60 times too low on a one-minute bucket. +- Pie, table and bar breakdowns now agree with the line chart they came from. diff --git a/apps/landing/src/content/changelog/2026-11-06-slos.md b/apps/landing/src/content/changelog/2026-11-06-slos.md new file mode 100644 index 0000000000..d8e683b00f --- /dev/null +++ b/apps/landing/src/content/changelog/2026-11-06-slos.md @@ -0,0 +1,26 @@ +--- +title: "SLOs with burn-rate alerts" +description: "Set an availability or latency objective on a service, watch its error budget, and get paged when the budget burns too fast." +date: 2026-11-06 +category: alerts +authors: [makisuo] +--- + +You can now define **service level objectives** in Maple. An SLO covers one service's incoming +requests, optionally limited to some environments, and has: + +- an **SLI**: availability (requests that did not fail) or latency (requests faster than a + threshold from 50 ms to 10 s); +- a **target**, such as 99.9%; +- a rolling **window** of 7, 28 or 30 days. + +Each SLO alerts on how fast it spends its error budget, not on single spikes. A **critical** page +fires when the budget burns at 14.4 times the sustainable rate over both the last hour and the last +5 minutes. A **warning** fires at 6 times over both the last 6 hours and 30 minutes. A brief blip +does not page, and the page clears as soon as the burn stops. The notification says which windows +are burning and how fast. A gap in incoming data holds the alert where it is instead of resolving +it. + +Find SLOs under **Alerts → SLOs**. Each SLO's page shows the SLI against the target, the budget +left, the budget over time, the burn rate of each window, and its incidents. SLOs are also +available from the `/v2/slos` API and MCP. diff --git a/apps/landing/src/content/changelog/2026-11-07-end-users.md b/apps/landing/src/content/changelog/2026-11-07-end-users.md new file mode 100644 index 0000000000..1adf67d76a --- /dev/null +++ b/apps/landing/src/content/changelog/2026-11-07-end-users.md @@ -0,0 +1,22 @@ +--- +title: "A Users page for the people using your product" +description: "See every end user your app identifies, with their sessions, errors, requests and MCP activity on one page." +date: 2026-11-07 +category: platform +authors: [makisuo] +--- + +**Analyze → Users** lists the end users of your product: everyone your SDKs identify, through +`identify()` in the browser or `user.id` / `enduser.id` on spans. It is now on for every +organization. + +- **The directory** shows each user's sessions, errors and requests, when they were last seen, and + where their requests come from (web, mobile, API or MCP). Filter to users with errors or with + replays, and group users by the group you pass to `identify()`, such as their company. +- **A user's page** shows their identity, traits and devices, and tabs for activity, session + replays, product events and the MCP sessions they ran, merged into one timeline. +- **Issues** show how many users an error affected, and a user shows the errors they hit. + +Use it to answer a support ticket ("what did this customer see?") or to check who a bad deploy +reached. The same data is available from the `/v2/users` API and the `list_users` and +`inspect_user` MCP tools. diff --git a/apps/landing/src/content/changelog/2026-11-07-on-call.md b/apps/landing/src/content/changelog/2026-11-07-on-call.md new file mode 100644 index 0000000000..c552ef7875 --- /dev/null +++ b/apps/landing/src/content/changelog/2026-11-07-on-call.md @@ -0,0 +1,56 @@ +--- +title: "On-call in Maple: schedules, escalation, acknowledgements and silences" +description: "Page whoever is on call, escalate until someone acknowledges, and silence alerts during a deploy, without a separate paging tool." +date: 2026-11-07 +category: alerts +authors: [makisuo] +--- + +Maple alerts now cover the whole path from a firing rule to the person who fixes it. Everything +below is in the **Alerts** hub. + +## Acknowledge an incident + +Click **Acknowledge** on an incident or in the inbox, or on the alert card in Slack or Discord, to +tell your team you are on it. While an incident is acknowledged, reminders stop. If it gets worse +and moves from warning to critical, it pages again. When the incident already paged PagerDuty, the +acknowledgement is sent there too. The inbox lists unacknowledged incidents first, and the +incident timeline records who acknowledged it and from where. + +## Escalation chains + +A chain is a list of steps: notify these destinations or people, then wait a number of minutes for +someone to acknowledge before the next step. For example, "post to #alerts, then page the on-call +after 10 minutes, then the team lead". A chain can repeat. Build chains on the **Routing** tab and +attach one to a rule's warning or critical tier. Acknowledging pauses the chain, and the incident +page shows which step it is on and when the next page goes out. + +## On-call schedules + +The new **On-call** tab holds your rotations. A schedule has a time zone and up to five layers, +each rotating its people daily, weekly or every few hours, optionally only in some hours or days +(weekends, or 22:00 to 06:00). An override covers a shift for someone else. Each schedule has a +week calendar with the final rotation and its overrides, and the inbox shows who is on call now. +An escalation step can page "whoever is on call" on a schedule, by email, Slack direct message or +Discord direct message. + +## Silences + +Silence alerts for a deploy or a planned migration without turning rules off. Silence one rule or +one incident's group for 1 hour, 4 hours, until 09:00 or a custom end, or create a silence on the +**Silences** tab that matches rules by service, environment or tag. Rules keep evaluating while +silenced. If an incident is still open when the silence ends, its page goes out then. + +**Maintenance windows** are recurring silences, such as "every Sunday 02:00 to 04:00 in +Europe/Berlin", and keep planned downtime out of anomaly baselines. For now they are set up through +the API and MCP; the dashboard comes next. + +## Anomalies route like alerts + +Detected anomalies now page through alert rules, so they get destinations, warning and critical +tiers, acknowledgement, silences and escalation like any other alert. Open anomalies are the +**Anomalies** view of the inbox, and an anomaly rule can be scoped to services, environments and +signals. Paging on anomalies stays off until you add a destination. + +All of this is available from the API and the MCP server as well, so an agent can ask who is on +call, acknowledge an incident or silence a noisy rule. diff --git a/apps/landing/src/content/docs/agent-tracing.mdx b/apps/landing/src/content/docs/agent-tracing.mdx index 8724ad0987..0effb96145 100644 --- a/apps/landing/src/content/docs/agent-tracing.mdx +++ b/apps/landing/src/content/docs/agent-tracing.mdx @@ -53,7 +53,7 @@ export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer YOUR_INGEST_KEY" export OTEL_SERVICE_NAME="support-agent" ``` -Maple doesn't accept gRPC, so set the protocol to `http/protobuf` if your exporter defaults to it. A traces endpoint passed in code or through `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` must end in `/v1/traces`. +Maple accepts OTLP over HTTP and gRPC on the same host. The examples on these pages use `http/protobuf`. A traces endpoint passed in code or through `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` must end in `/v1/traces` over HTTP. Keep agent traffic at 100% sampling, or sampled-out turns leave gaps in the session. See [Sampling and throughput](/docs/concepts/sampling-throughput). diff --git a/apps/landing/src/content/docs/agent-tracing/microsoft-agent-framework.mdx b/apps/landing/src/content/docs/agent-tracing/microsoft-agent-framework.mdx index 825b3b8276..4e9971e450 100644 --- a/apps/landing/src/content/docs/agent-tracing/microsoft-agent-framework.mdx +++ b/apps/landing/src/content/docs/agent-tracing/microsoft-agent-framework.mdx @@ -69,7 +69,7 @@ else: logging.getLogger(__name__).warning("MAPLE_INGEST_KEY is not set; Maple telemetry export is disabled") ``` -Keep `otlp_protocol="http/protobuf"`. MAF defaults to gRPC, which Maple doesn't accept. +Keep `otlp_protocol="http/protobuf"`. MAF defaults to gRPC, and the install above only adds the HTTP exporter. If your app already has a `TracerProvider`, don't call `configure_otel_providers()`. Add Maple's exporter and `ConversationIdProcessor` to your provider, then call `enable_instrumentation(enable_sensitive_data=True, enable_message_events=False)` from `agent_framework.observability`. diff --git a/apps/landing/src/content/docs/getting-started/quickstart.mdx b/apps/landing/src/content/docs/getting-started/quickstart.mdx index 4c4d236257..2d92db4d87 100644 --- a/apps/landing/src/content/docs/getting-started/quickstart.mdx +++ b/apps/landing/src/content/docs/getting-started/quickstart.mdx @@ -108,7 +108,7 @@ opentelemetry-instrument python app.py # or: opentelemetry-instrument uvicorn main:app ``` -Send a request to your app. FastAPI, Django, Flask and the common HTTP and database clients are traced automatically. Keep `OTEL_EXPORTER_OTLP_PROTOCOL` from step 3: the distro defaults to gRPC, which Maple does not accept. The wrapper does not work with `uvicorn --reload`. For logs, metrics and a setup in code, see the [Python guide](/docs/guides/instrumentation-python). +Send a request to your app. FastAPI, Django, Flask and the common HTTP and database clients are traced automatically. Keep `OTEL_EXPORTER_OTLP_PROTOCOL` from step 3: the distro defaults to gRPC, and only the HTTP exporter is installed. The wrapper does not work with `uvicorn --reload`. For logs, metrics and a setup in code, see the [Python guide](/docs/guides/instrumentation-python). diff --git a/apps/landing/src/content/docs/reference/ingest.md b/apps/landing/src/content/docs/reference/ingest.md index 3805bdae7d..de1eae2707 100644 --- a/apps/landing/src/content/docs/reference/ingest.md +++ b/apps/landing/src/content/docs/reference/ingest.md @@ -5,12 +5,12 @@ group: "Reference" order: 3 --- -Every signal reaches Maple through one OTLP/HTTP gateway. Any OpenTelemetry SDK or Collector that can export OTLP over HTTP works without a Maple-specific exporter. +Every signal reaches Maple through one OTLP gateway, over HTTP or gRPC. Any OpenTelemetry SDK or Collector that can export OTLP works without a Maple-specific exporter. | | | | ------------ | ------------------------------------------------------------------------------------- | | Base URL | `https://ingest.maple.dev`, or your [region's](/docs/reference/regions) ingest host | -| Protocol | OTLP over HTTP, `POST` | +| Protocol | OTLP over HTTP (`POST`), or OTLP over gRPC on port 443 (see [gRPC](#grpc)) | | Auth | `Authorization: Bearer maple_pk_…` (or `maple_sk_…`, or a `maple_src_…` source token) | | Encodings | Protobuf (recommended) or JSON, optionally gzip | | Max body | 20 MiB per request, measured on the compressed body; 160 MiB once decompressed | @@ -35,6 +35,18 @@ export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer maple_pk_…" export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf" ``` +## gRPC + +Traces, logs and metrics can also be sent over OTLP/gRPC to the same host on port 443, with TLS. Product events, session replays and session events are HTTP only. + +```bash +export OTEL_EXPORTER_OTLP_ENDPOINT="https://ingest.maple.dev" +export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer maple_pk_…" +export OTEL_EXPORTER_OTLP_PROTOCOL="grpc" +``` + +gzip compression and the request limits are the same as over HTTP. Errors come back as gRPC status codes: `RESOURCE_EXHAUSTED` for a body over the limit, `UNAVAILABLE` for a timeout or a temporary failure (retry it), and `INVALID_ARGUMENT` for a malformed request. + ## Authentication Send your ingest key on every request, either as a Bearer token or in the `x-maple-ingest-key` header. The `Bearer` prefix is case-insensitive.