Posts

Posted on

Monitoring vs Observability

What is the difference between monitoring and observability?

Monitoring is process of collecting live events from your application, traces, debug messages, warnings and exceptions. The same process may involve sending those events to some storage or application that analyze or visualize those messages. I.e. in asp.net core applications monitoring of application involves calling a ILogger and sending those logs or critical exceptions to AppInsights. Monitoring may also involve activity of development team members to active watch those logged messages for any potential errors or problems that may impact availability of production environment.

Observability is on the other hand is analyzing messages produced by monitoring process to understand behavior of application and reason about it internal state, if this state is expected (correct behavior, ‘application works ok’) or may be unexpected (erroneous state, database is down, endpoints returns 500 etc). Typically involves dashboard with several metrics from monitoring, exceptions, response times, number of not OK responses in time, long database queries, number of active users etc (i.e. App Insights dashboard in asp.net core). Monitoring process of an application (as human activity) is typically using such observability dashboard.

So what is the difference between Observability and Monitoring? Observability is possible because Monitorin of an application was implemented. If metrics and logs would not be collected and stored system is not observable.

Basically Monitoring is collecting logs and metrics, while Observability is feature of the system enabled by such process.

Posted on

Solid

  • The single-responsibility principle – piece of software should have only one responsibility
  • The open–closed principle – things should be open for extension but closed for modification
  • The Liskov substitution principle – changing interface implementation should not brake software
  • The interface segregation principle – it is better to have more specialized interfaces than single big one
  • The dependency inversion principle – dependencies should be abstracted via interfaces

Further read:

https://en.wikipedia.org/wiki/SOLID

Posted on

.NET/C# interview questions

Posted on

Equals and GetHashCode

Custom implementation is usually only necessary if default, reference equality is not enough. In example:

  • entities value based equality
  • value equality of deserialized objects
  • custom comparisons based on other criterias
public class ImaginaryNumber : IEquatable<ImaginaryNumber>
{
    public double RealNumber { get; set; }
    public double ImaginaryUnit { get; set; }

    public override bool Equals(object obj)
    {
        return Equals(obj as ImaginaryNumber);
    }

    public bool Equals(ImaginaryNumber other)
    {
        return other != null &&
               RealNumber == other.RealNumber &&
               ImaginaryUnit == other.ImaginaryUnit;
    }

    public override int GetHashCode()
    {
        return HashCode.Combine(RealNumber, ImaginaryUnit);
    }
}