Руководство Разработчика для Cisco Cisco Firepower Management Center 4000
2-11
FireSIGHT eStreamer Integration Guide
Chapter 2 Understanding the eStreamer Application Protocol
Event Stream Request Message Format
The following table describes each field in Event Stream Request messages.
Initial Timestamp
Note
Your client application should use the archival timestamp in the Initial Timestamp field when submitting
an event stream request, as explained below. This ensures that you do not inadvertently exclude events.
Devices transmit data to the Defense Center using a “store and forward” mechanism with transmission
delays. If you request events by the generation timestamp assigned by the device that detects it, delayed
events may be missed.
an event stream request, as explained below. This ensures that you do not inadvertently exclude events.
Devices transmit data to the Defense Center using a “store and forward” mechanism with transmission
delays. If you request events by the generation timestamp assigned by the device that detects it, delayed
events may be missed.
When starting a session, a best practice is to start up from the archival timestamp (also known as the
“server timestamp”) of the last record in the previous session. It is not a technical requirement but is
strongly recommended. Under certain circumstances, if you use the generation timestamp you can
inadvertently exclude events from the new streaming session.
“server timestamp”) of the last record in the previous session. It is not a technical requirement but is
strongly recommended. Under certain circumstances, if you use the generation timestamp you can
inadvertently exclude events from the new streaming session.
To include the archival timestamp in your streamed events, you must set bit 23 in the request flag field.
Note that only time-based events have archival timestamps. Events that eStreamer generates, such as
metadata, have zero in this field when extended event headers have been requested with bit 23 set.
metadata, have zero in this field when extended event headers have been requested with bit 23 set.
Request Flags
You set bits 0 through 29 in the event data request flag field to select the types of events you want
eStreamer to send. You set bit 30 to activate the extended request mode. Setting bit 30 does not directly
request any data. Extended request flags must be sent if this bit is set. Your client requests data during
the server-client message dialog that follows submission of the Event Stream Request message. For
information on extended requests, see
eStreamer to send. You set bit 30 to activate the extended request mode. Setting bit 30 does not directly
request any data. Extended request flags must be sent if this bit is set. Your client requests data during
the server-client message dialog that follows submission of the Event Stream Request message. For
information on extended requests, see
See
for definitions of the bit settings in the Request Flags field. Different flags
request different versions of the event data. For example, to obtain data in FireSIGHT System 4.9 format
instead of 4.10 format you set a different flag bit. For specific information on the flags to use when
requesting data for particular product versions, see
instead of 4.10 format you set a different flag bit. For specific information on the flags to use when
requesting data for particular product versions, see
.
Table 2-5
Event Stream Request Message Fields
Field
Data Type
Description
Initial
Timestamp
Timestamp
uint32
Defines the start of the session. To start at:
•
the time the client connects to eStreamer, set all timestamp bits to
1
.
•
the oldest data available, set all timestamp bits to zero.
•
a given date and time, specify the UNIX timestamp (number of
seconds since January 1, 1970).
seconds since January 1, 1970).
See
below for important information.
Request Flags bits[32]
Specifies the types and versions of events and metadata to be returned
in event stream requests. See
in event stream requests. See
for flag
definitions.
Setting bit 30 initiates an extended request, which can co-exist with
event stream requests in the same message.
event stream requests in the same message.