GRAPHIC: New Entity Operations™ Alpha Logo

EntityScript



Alerts and Logging in C.ORE™



Use the built-in user-space audit framework that helps your isolate computational-processes into observable parts. Here is a brief overview of how that works.


Log File Types

Logs are automatically generated by the C.ORE™ program and adhere to a thread-based model that establishes rules for each running sub-process before hand, where each thread is a potential to log a process. Each process can be stored as they occur and they are defined storage outcomes when the audit framework is in place around the specific code-block. These outcomes are segmented into silos when logged and some are set to on/off by default, but more be generated.

Each logged silo works based off of user-defined types. Some of those types are presets and self-created at the programs startup. Others can be selectively turned on.

At any given time while the program is "up" there is one main process running. By default, async behavior isn't included but can be branched to a async process handler. There is also a personal instance server that survives base program termination and runs as a separate process until it's killed manually. This methodology can be made so it only operates while the program is in an up state. Each running thread is able to process data as if they were sub-states because they aren't blocking. Only 1 process runs at a time by default - unless multiple instances are activated. This is a possiblity.

Each process isn't bound to each other at all. Instead - processes are linked to each other. These states can be branched or forked into new kinds of behavior too. Running under a read-only stateful sub-system, these silos provide a way to group outcomes into log like storage containers easily. Read through the .CORE/core_alerts.py file for more details and for relevant doc string overviews regarding functionality.

These log file silos should all be wiped and set back up at set intervals. They should only be run based on scripts used in the extensions sections and tied in correctly using a connector object of some established convention type. The operating system in use underneath everything can change each added behavior slightly and will cause some different methods and processes to run slightly different on each system as they occur. The way processes run on each machine may vary slightly too depending on the virtual environment chosen and hardware. It's not recommended to add any random behavior to the logging framework or to try to implement your own logging routines. It's better to follow the provided framework - the framework provides any type of needed auditing. Follow the set computing-transaction methodology available in the preset methods for activities, events, and searches.

Logs are meant to be processed every few days. Ideally, that process should strip the necessary information from the log and reset the file to a base instance. A base-instance is considered "clean". A clean file is also used to describe any other type of storage container that is EntityScript™ compliant. An EntityScript™ compliant data container takes the extension .es. By default .es files that are generated are stored in DATA/. The data kept in each container should be of an exact type and be stored for an exactly defined software process existing within the system according to a time-schedule and operations enforcement criteria. These time schedules can take "Alerts". All "Alerts" are the way that common data-type events flow into .es files, even when they aren't explicitly logs of each of them in detail.

Default system activity logs to 1 and only 1 file that exists in DATA/ACTIVITY/.

This file is significant and can be used to generate general automation routines. This is a log file, the only defined one from the state and simply is named log.es

There should be zero extra files in the .CORE/DATA/LOGS/ section once automation and processing of those types for log-specific files occurs. By default, your logging behavior can be branched into this location and can serve as a web server logging mechanism, system event logger, a firewall logger, and more. Only data that has already been processed and archived according to an exact format should remain here after these automation routines occur, because it's meant to exist on the fly. Any other logging-based file that isn't processed through C.ORE™ should be isolated into a "unprocessed bucket (z_ or ZZZ_)" and went through by a human according to set "archiving" principals.

If there are any extra logs that aren't "cleaned", you're behind in a way that can get the machine into trouble later on. Logs should always be processed and cleaned according to the desired time-interval and long-term storage objective. This helps the operator get accurate and timely insights and also helps keep the system current.


The goal og the audit framework and logs is to have a parser for each type of log that produces general yet descriptive output.

These logs then are written into longer-term storage according to an exact time-schedule. All of these logs should only exist within:
.CORE/DATA/LOGS/*


Data containers table

All data containers are stored in DATA/ besides the exceptions of log.es or other log_*.es files stored in DATA/ACTIVITY/ or DATA/LOGS/



ID name of container type of data description of data
1 accessglobal.es communication Peer access records
2 accessvalues.es fed-by fed-by: accessglobal.es to provide options for retrieving linked data hosted elsewhere.
3 ACTIVE_ENTITY.es cache cache of the last loaded entity
4 active_member.es system-lookup a record of the last known system member. Used in auditing and access control.
5 blob_object.es blob a branch-able data container that feeds ingest_commands
6 CLEANEROFCOURSE_MANIFEST.es system-routine instructions on what locations to clean during automation.
7 CONSTRUCTED_core.es system-routine manually or continuously logged communications
8 core.es communications communications general write-to bucket
9 core_packages.es system-routine output of the system-level packages installed by the implementation language
10 data.c structure define input structures. Branch multiple structures into a general binary ready readable and writable container.
11 ENTITY_MANIFEST.es system-routine check and organize what system C.ORE™ is currently aware of
12 HASH_DIRECTORY.es system-routine output information from performing hash verifications on a file
13 KEY.es system-routine provides a lookup match device to use a keycard or other password-less authentication mechanism.
14 log.es system-routine general session specific log output
15 ORE_LEDGER.es entityscript-ore ORE/ retrieval information
16 output_entity.es entity-output take constructed class objects and output them
17 output_flush.es output-flush flush initialized constructed class objects. Free the information buffer
18 output_slug.es output-slug A structured output of a constructed class
19 output_structure.es output-structure comma separated structure table created by the constructed class
20 output_vectorized_data.es output-vectorized-data the same as output_structure but the data is in the form of vector object formatting
21 STRUCTURE.es system-routine the linked attributes currently in place and discoverable by C.ORE™
22 vcnkey.es vcnkey VCNKEY™ based block storage lookup system
23 VISUAL.es system-routine Information to access various visual resources


There are preset types of data that you can store:

blob General multi-data unstructured or undefined I/O processor logs

cache General on-the-fly data process logging, usually temporary in nature

communication Server communication logs

communications Personal server communication logs

entity-output formatted output logs

entityscript-ore Retrieval-protected logs of various types

fed-by Logs that are being pulled in from other generated log access-points

output-flush Logs that are ready to be flushed at the start of a new instance

output-slug Logs that meant to process a constructed class data output module

output-structure EntityScrtip™ compliant logged structures

output-vectorized-data Vector-ready compliant logged structure

structure A log type that allows the feeding of another log

system-lookup A system generated log from a processess that was pre-defined by the program

system-routine Automation focused logs that are kicked off by a machine process

vcnkey: The output of a block-transaction with CORE.HOST™



Alert Types:

Alert Types can be used to trigger extended behavior in C.ORE™

FULL LIST COMING SOON

identified signal: THREAT_
SCORE_INFO Create a logged `info` method

identified signal: THREAT_
SCORE_WARNING Create a logged `warning` method

identified signal: THREAT_
SCORE_FAILURE Create a logged `failure` method

Action Tags

Action Tags can be used to track link actions in C.ORE™

Action tags can be used as log augment mechanisms and hold several functions. Here are few.

activation call: ACTION_
REGULAR Standard action recorder

activation call: ACTION_
AUDITED Standard protected action recorder

activation call: ACTION_
ENTITYSCRIPT_RECORDER Used when activating EntityScript™ blocks

activation call: ACTION_
KING_SLUG_RECORDER Used when activating a new active block groups

activation call: ACTION_
SEARCH_RECORDER Used when performing a standardized search lookup


To see more about creating Meta-relationships: Standard Types and core_creator.py, click OpenPackager™