Serverless functions
Functions, their invocations, and the cold starts that make them slow.
How functions are detected #
A function is detected from the resource attributes on your invocation spans. Send faas.name, cloud.provider and cloud.region, and the function is listed with everything you would want to know about it.
- Function — its name, provider, region and runtime.
- Invocations — how many times it ran in the window.
- Errors — invocations that failed.
- Cold starts — invocations that began a new instance.
- Latency — average, 95th percentile and maximum.
- Memory — the configured maximum.
- Triggers — what invoked it.
- Instances — how many were used.
Cold starts #
An invocation is a cold start when the platform reports faas.coldstart. Cold starts are the usual reason a function's tail latency is worse than its average, so the two are shown side by side.
faas.name
faas.coldstart
faas.max_memory
faas.trigger
cloud.provider
cloud.region
Triggers #
The trigger field records what invoked the function — an API gateway, a queue, a schedule. Grouping by trigger shows which path is driving volume.
Investigating a slow function #
- Compare average latency with the 95th percentile to see whether the tail is the problem.
- Check the cold start count against the instance count; many invocations across few instances indicates churn.
- Filter by trigger to isolate one invocation path.
Function identity
A function's identity is its provider, region and name. Keeping the name stable across deployments keeps its history together.
Onward #
A function is a resource like any other, so it also appears in the resource catalogue. For who calls it, Network flows and Data streams monitoring.