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/

---

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™

---