Logback -custom level input in layout pattern

i am using logback for logging and in logback.xml i have Console appender as

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>

              <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
            </encoder>
    </appender>.

i am trying to achieve something like this...

time  thread  |-**CUSTOMLOGLEVEL**  xyz.class - Message.

Why ? i want to filter the messages easily by defining the loglevel or some other indicator.

for example: search logs with log level "CUSTOMLOGLEVEL". Is there any way to give custom log level or any other indicator which shows that this is custom generated log and not some framework generated log..

i went into direction of creating custom class .

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
         <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="com.logging.CustomLayout">
                             <param name="argument1" value="1" />
                             <param name="argument2" value="2" />

            </layout>
        </encoder>
    </appender>

but i am not sure how i will give input externally to these parameters.

In case i am not clear please let me know .

Solution

SLF4J/Logback solves the problem of "I want to do something more complex than a log level" with a feature called Markers.

For example, to mark some logs as "interesting":

Marker interesting = MarkerFactory.getMarker("INTERESTING");
Logger logger = LoggerFactory.getLogger(getClass());
…
logger.info(interesting, "Something happened: {}", value)

In the PatternLayout, one can use %marker to record the marker associated with a log entry. (See %marker in the documentation.)

This is similar to what's in a SLF4J FAQ entry on why they don't have a "FATAL" level and how to use Markers.

Another option (since you're specifically asking about filtering to see if it's a "custom generated log and not some framework generated log") is to ensure that your custom logs are all in a logger that's named what you want (maybe starting with com.yourcompany.custom.), and just using the normal logger filtering. While it's often very handy to have loggers be named after the class that they're in, sometimes using a different name for different loggers more accurately represents what you're trying to log, and allows for easy filtering and searching as well.