Lumar Log Manager
Lumar Log Manager ingests access logs directly from your CDN or web host, so your crawls carry log file analysis data without you running a log platform of your own. It is the successor to the Logz.io and Splunk integrations, which remain supported.
Two objects make up the integration:
- A log source (
LogManagerConnection) — one per place your logs come from, owned by the account. - A project attachment
(
LogManagerProjectSettings) — links a log source to one project and holds that project's ingestion settings. One log source can feed many projects, each with its own settings.
Lumar Log Manager is in early access and is enabled per account. Four mutations require it to be
enabled and return a feature-not-available error otherwise: createLogManagerConnection,
updateLogManagerConnection, createLogManagerProjectSettings and
updateLogManagerProjectSettings. Contact your Lumar account manager to have it switched on.
Reading your log sources and settings, and both delete mutations, stay available whether or not it is enabled — so an account that had it switched off can always inspect and remove what it already has. The surface described here may still change before general availability.
How setting up a log source works
Unlike the Logz.io and Splunk integrations, you do not supply credentials through the API. Creating a log source registers a request with Lumar; our support team then builds the delivery pipeline with you and exchanges any credentials out of band. The flow is:
- You create the log source. It is returned with
status: BeingConfiguredand a Lumar-generatedtenantId. - Lumar support contacts you, sets the delivery up, and moves the source to
Connected— or toConnectionErrorwith astatusMessageexplaining what is blocking it. - You attach the source to the projects that should use it.
You can attach a source to projects at any point, including while it is still BeingConfigured;
logs start flowing into crawls once the source reaches Connected.
status and statusMessage are set by Lumar support, not by API clients — there is no input field
for them. Poll the source (or watch it in the app) to see where configuration has got to.
Listing the available providers
getLogManagerProviders returns the CDNs and web hosts a log source can be created for, grouped by
category and ordered for display. It is static reference data and needs no account context.
query GetLogManagerProviders {
getLogManagerProviders {
provider
name
category
displayOrder
}
}
If your provider is not in the list, create the source with provider: Other and describe your
setup when Lumar support gets in touch.
Creating a log source
Requires the Admin role on the account.
mutation CreateLogManagerConnection($input: CreateLogManagerConnectionInput!) {
createLogManagerConnection(input: $input) {
logManagerConnection {
id
name
provider
status
tenantId
}
}
}
Notes on the response:
statusis alwaysBeingConfiguredon creation.tenantId(for examplelm_9f3a4b7c1d2e5f60) is the handle Lumar uses to identify this source's log pipeline. Quote it when you contact support about the source. It is an identifier, not a secret — credentials are never carried on this object. For an existing delivery pipeline, support can match this value to its tenant identifier. Do not assume that every tenant identifier starts withlm_or remains unchanged.providercannot be changed afterwards. If you move to a different CDN, create a new log source and delete the old one.
name must be unique within the account; a duplicate is rejected.
Listing log sources
Log sources hang off the account.
query GetLogManagerConnections($accountId: ObjectID!) {
getAccount(id: $accountId) {
logManagerConnections(first: 10, orderBy: [{ field: createdAt, direction: DESC }]) {
nodes {
id
name
provider
status
statusMessage
tenantId
createdAt
projects {
totalCount
}
}
totalCount
pageInfo {
hasNextPage
endCursor
}
}
}
}
status is one of:
| Status | Meaning |
|---|---|
BeingConfigured | Lumar support is setting the delivery pipeline up. No logs are flowing yet. |
Connected | The pipeline is delivering. Attached projects pick logs up on their next crawl. |
ConnectionError | Delivery has stopped or could not be established. Read statusMessage for the explanation, which is written by Lumar support. |
statusMessage is null unless there is something to explain. Moving a source off
ConnectionError clears it, unless Lumar support sets a new message in the same update — so a
Connected source can still carry one. Read status to decide whether a source is in error, not
the presence of a message.
projects is a standard connection — select totalCount alone to get the "projects using this
source" count without fetching the rows. It only counts projects you have access to.
You can filter and sort the connection on name, provider, status, tenantId, createdAt and
updatedAt; see Filtering and Sorting.
Renaming a log source
Requires the Admin role. name is the only field an API client can change.
mutation UpdateLogManagerConnection($input: UpdateLogManagerConnectionInput!) {
updateLogManagerConnection(input: $input) {
logManagerConnection {
id
name
status
}
}
}
Attaching a log source to a project
Requires the Editor role on the account that owns the project. The log source and the project must belong to the same account.
mutation CreateLogManagerProjectSettings($input: CreateLogManagerProjectSettingsInput!) {
createLogManagerProjectSettings(input: $input) {
logManagerProjectSettings {
id
enabled
dateRange
}
project {
id
name
}
}
}
Every field except projectId and logManagerConnectionId has a default, so the mutation above is
close to the minimum you need. The settings are:
| Field | Default | What it does |
|---|---|---|
enabled | true | Whether this source feeds the project's crawls. Set false to pause it without detaching. |
dateRange | 30 | How many complete days of logs to fetch. See below. |
desktopUaRegexp / desktopUaNotRegexp | Googlebot desktop | User agents counted as — and excluded from — desktop bot requests. |
mobileUaRegexp / mobileUaNotRegexp | Googlebot mobile | The same, for mobile bot requests. |
aiUaRegexp / aiUaNotRegexp | common AI crawlers | The same, for AI bot requests. |
A crawl reads the most recent dateRange complete days in the log store. A day counts as complete
once the following day's logs have arrived, so the window usually ends the day before the crawl.
baseUrl, useLastCrawlDate and maxRows are deprecated. maxRows is ignored: log extraction never
capped the rows it reads. useLastCrawlDate is also ignored: the window is always
dateRange days. baseUrl still applies while set, but will be removed; log paths will then
resolve against the project's primary domain.
The three user-agent buckets are what the log file analysis reports break traffic down by. The
defaults track Googlebot and the mainstream AI crawlers; override them if you want to measure a
different set of bots. See
CreateLogManagerProjectSettingsInput
for the exact default patterns.
Constraints worth knowing before you script this:
- A project can have at most 30 log sources attached (
TOO_MANY_LOG_MANAGER_PROJECT_SETTINGS). - The same log source cannot be attached to the same project twice.
- Test suites cannot have log sources attached; attach the source to the project instead.
Reading a project's log settings
query GetLogManagerProjectSettings($projectId: ObjectID!) {
getProject(id: $projectId) {
logManagerProjectSettings(first: 10) {
nodes {
id
enabled
dateRange
desktopUaRegexp
mobileUaRegexp
aiUaRegexp
logManagerConnection {
id
name
status
}
}
totalCount
}
}
}
Changing a project's log settings
Requires the Editor role. Omitted fields are left unchanged. The three ...NotRegexp
fields accept an explicit null to clear them.
mutation UpdateLogManagerProjectSettings($input: UpdateLogManagerProjectSettingsInput!) {
updateLogManagerProjectSettings(input: $input) {
logManagerProjectSettings {
id
enabled
dateRange
}
}
}
Detaching a log source from a project
Requires the Editor role. Removes the settings for that one project. The log source itself, and its other projects, are untouched.
mutation DeleteLogManagerProjectSettings($input: DeleteLogManagerProjectSettingsInput!) {
deleteLogManagerProjectSettings(input: $input) {
logManagerProjectSettings {
id
}
project {
id
}
}
}
Deleting a log source
Requires the Admin role.
mutation DeleteLogManagerConnection($input: DeleteLogManagerConnectionInput!) {
deleteLogManagerConnection(input: $input) {
logManagerConnection {
id
name
}
}
}
Deleting a log source also detaches it from every project it was attached to — you do not need to remove the project settings first, and there is no confirmation step. Lumar support is notified so the delivery pipeline on the provider side can be decommissioned.
Deletion stays available when a subscription has lapsed, so you can always switch off a log feed you are no longer paying for.