Log event shipping

Getting application logs into Loggly is exactly what this connector is for. As events occur in your systems, the agent reads each entry, applies a customer-approved rule about what belongs in Loggly, and forwards the qualifying events to your account. What was shipped and when is written back locally so there is a record on your side. Events that arrive malformed, exceed a size the rule permits, or carry fields marked as private are held rather than forwarded, and a person decides whether to scrub, resize, or drop them before they leave your environment for the log service.

Event tagging

Tags make logs findable later, so the agent adds them as events go out. Reading each entry, it applies an approved rule to attach the right tags, environment, service, or severity, before the event is sent to Loggly. The tags chosen are noted alongside the shipped record so the scheme stays consistent. When an event does not fit any tagging rule, or carries conflicting signals about which tag applies, the agent forwards it with a default marker and asks a person to confirm the tag, keeping mislabeled events from muddying later searches.

Send-only boundary

This connector sends data to Loggly but does not read it back; separate credentials are needed for that. An agent works within that limit on purpose: it prepares and forwards events, and keeps its own local note of what left, without promising to query results from Loggly afterward. Any task that asks to search or pull stored logs is recognized as out of scope and routed to a person, who uses the read credentials or the Loggly interface directly. This keeps the agent honest about what it can and cannot confirm from here.