feat(docs): document Metering & Billing plugin event dimensions

[gergely-kurucz-konghq]

Description

What

• Adds a Captured event dimensions section to the Metering & Billing plugin page (## How it works), with a table per emitted event type (kong.api_request, kong.llm_request) plus the conditional portal/application fields. Rendered from a new _data file via an include.
• Links each guide's "Create a meter" step to that reference.

Why

The plugin page said it "captures standard Kong Gateway metadata" but never listed the fields it emits — that dimension catalog was undocumented. The how-to guides show only a curated subset, so readers had nowhere to find the complete set.

How

Field lists are transcribed from the plugin source cloudevent.lua (create_api_event / create_ai_event). The table is data-driven (app/_data/plugins/metering-and-billing.yaml + app/_includes/plugins/metering-and-billing/event_dimensions.md), following the existing OTel metric_tables.md pattern. Operator-configured custom attributes are documented as an extension mechanism (they can't be enumerated from source). Render-checked locally: both event tables + portal table render, and both guide links resolve to #captured-event-dimensions.

Fixes https://konghq.atlassian.net/browse/OM-433

Preview Links

• /plugins/metering-and-billing/#captured-event-dimensions
• /metering-and-billing/get-started/#create-a-meter
• /how-to/meter-llm-traffic/#create-a-meter

Checklist

• Tested how-to docs. Render-verified the plugin page and both guide links locally.
• All pages contain metadata.
• Any new docs link to existing docs.
• All autogenerated instructions render correctly (API, decK, Konnect, Kong Manager).
• Style guide (capitalized gateway entities, placeholder URLs) implemented correctly.
• Every page has a description entry in frontmatter.
• Add new pages to the product documentation index (if applicable). — N/A, no new pages (a section on an existing page).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ lena-larionova
❌ gergely-kurucz-konghq
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[netlify]

✅ Deploy Preview for kongdeveloper ready!

Name	Link
🔨 Latest commit	d6ffe82
🔍 Latest deploy log	https://app.netlify.com/projects/kongdeveloper/deploys/6a7380b808c19d0008ec22b3
😎 Deploy Preview	https://deploy-preview-6538--kongdeveloper.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[lena-larionova]

One nitpick, otherwise lgtm. We'll just need to make sure we keep this table updated for every 3.x release.

[gergely-kurucz-konghq]

One nitpick, otherwise lgtm. We'll just need to make sure we keep this table updated for every 3.x release.

@lena-larionova My idea is to propose to the plugin developers to annotate the relevant parts of the M&B Plugin code, so that the data fields are documented. (I will put up a PR about this for them.) Then, from this annotation, a JSON file can be exported, listing all the well-known fields. Then, in docs, we could track this JSON export of the fields, to implement a "drift detection" check (compare the JSON field list against what we have in ‎app/_data/plugins/metering-and-billing.yam), which could run on a daily schedule. I think I have seen something similar (scheduled check) in this repo. WDYT?

[lena-larionova]

One nitpick, otherwise lgtm. We'll just need to make sure we keep this table updated for every 3.x release.

@lena-larionova My idea is to propose to the plugin developers to annotate the relevant parts of the M&B Plugin code, so that the data fields are documented. (I will put up a PR about this for them.) Then, from this annotation, a JSON file can be exported, listing all the well-known fields. Then, in docs, we could track this JSON export of the fields, to implement a "drift detection" check (compare the JSON field list against what we have in ‎app/_data/plugins/metering-and-billing.yam), which could run on a daily schedule. I think I have seen something similar (scheduled check) in this repo. WDYT?

That makes sense to me, and would help us a lot. One question: can we assume that if they've merged the changes, that the changes are live to customers? Or are these gated behind API Gateway releases, since this is in the Gateway plugin?

[gergely-kurucz-konghq]

One nitpick, otherwise lgtm. We'll just need to make sure we keep this table updated for every 3.x release.

@lena-larionova My idea is to propose to the plugin developers to annotate the relevant parts of the M&B Plugin code, so that the data fields are documented. (I will put up a PR about this for them.) Then, from this annotation, a JSON file can be exported, listing all the well-known fields. Then, in docs, we could track this JSON export of the fields, to implement a "drift detection" check (compare the JSON field list against what we have in ‎app/_data/plugins/metering-and-billing.yam), which could run on a daily schedule. I think I have seen something similar (scheduled check) in this repo. WDYT?

That makes sense to me, and would help us a lot. One question: can we assume that if they've merged the changes, that the changes are live to customers? Or are these gated behind API Gateway releases, since this is in the Gateway plugin?

I am not fully aware of the how the release process of the GW plugins work, I will ask the team.