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
maxRows
useLastCrawlDate
}
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. |
baseUrl | project's primary domain | The base URL log paths are resolved against. |
dateRange | 30 | How many days of logs to fetch, counting back from the crawl. |
useLastCrawlDate | false | Fetch logs since the last finished crawl instead of using dateRange. Falls back to dateRange when the project has no finished crawl. |
maxRows | 10000000 | Maximum number of log rows to fetch per crawl. |
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. |
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
baseUrl
dateRange
useLastCrawlDate
maxRows
desktopUaRegexp
mobileUaRegexp
aiUaRegexp
logManagerConnection {
id
name
status
}
}
totalCount
}
}
}
Changing a project's log settings
Requires the Editor role. Omitted fields are left unchanged. baseUrl and the three
...NotRegexp fields accept an explicit null to clear them.
mutation UpdateLogManagerProjectSettings($input: UpdateLogManagerProjectSettingsInput!) {
updateLogManagerProjectSettings(input: $input) {
logManagerProjectSettings {
id
enabled
useLastCrawlDate
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.