►
From YouTube: Creating background .NET Core services on Linux
Description
There are a variety of ways to publish .NET Core applications. In the episode, Todd Gardner returns to share this experience with publishing self contained .NET applications to Linux.
[02:10] - What does the application architecture look like?
[04:42] - Exploring the worker processes
[10:50] - Collecting metrics
[12:55] - Self contained deployments
.NET Core application publishing overview
https://docs.microsoft.com/dotnet/core/deploying/?WT.mc_id=ondotnet-c9-cephilli
.NET Core logging and tracing
https://docs.microsoft.com/dotnet/core/diagnostics/logging-tracing?WT.mc_id=ondotnet-c9-cephilli
.NET Core and systemd
https://devblogs.microsoft.com/dotnet/net-core-and-systemd/?WT.mc_id=ondotnet-c9-cephilli
Request Metrics
https://requestmetrics.com/
#dotnet #systemd #linux #deployment
A
A
A
A
B
A
B
In
the
front
end,
I
built
a
product
called
track.js
which
does
error
monitoring
for
front-end
applications,
but
now
I'm
back
working
in
on
on
the.net
side
on
the
server
side,
because
I'm
building
something
new,
I'm
building
a
service
called
request,
metrics,
which
is
going
to
be
a
web
performance
monitoring
tool,
but
so
we're
standing
up
a
bunch
of
new
infrastructure
for
this
we're
building
up
new
code.
This
is
a
new
kind
of
thing
that
we're
doing
and
when
I
write
code,
that's
gonna
run
on
a
server.
B
A
B
Sure
sure
how
about
I
pull
up
some
architecture
and
I
can
kind
of
show
what
this
is
going
to
look
like,
so
we're
building
a
thing
called
request:
metrics
and
it's
going
to
be
a
brand
new
web
performance
monitoring
service,
so
think
of
a
service
that'll.
Tell
you.
How
fast
are
my
end?
Users
actually
experiencing
the
web
pages
and
api
endpoints
of
my
application?
B
It's
going
to
gather
all
that
information
from
real
user
interactions
and
aggregate
it
together
and
pull
together,
interesting
reports
and
that
sort
of
thing
this
is
our
initial
kind
of
sketch
of
the
architecture
that
we
started.
Building
from
and
the
bit
we're
going
to
talk
about
today,
specifically,
is
the
processor.
B
B
We
pick
up
it.
We
pick
it
up
with
nginx
and
we
write
it
into
a
log
file.
That's
all
we
do.
We
just
take
it
off
the
wire
and
we
shove
it
into
the
file
system
and
say:
hey
here's,
some
performance
data
for
us
to
process
later
and
it's
the
processor
that
actually
does
that
work.
It
finds
all
those
log
files
it
figures
out,
what's
meaningful
in
them,
rolls
up
some
data
processes,
alerts
on
data
and
saves
it
off
into
a
redis
redis
cluster.
B
B
B
Okay.
So
let's
have
a
look
at
this.
So
here
is
the
request.
Metrics
processor
and
it
probably
looks
like
most
console
apps-
that
all
of
us
have
written
dozens
and
dozens
of
times.
You
know,
there's
a
program
class
with
a
static
main
method
that
goes
off
and
does
some
things
and
for
the
most
part,
it
was
really
that
easy.
B
It
was
about
like
we're,
going
to
create
this
thing
and
off
and
running,
but
there
was
a
few
bits
that
just
needed
needed
something
special
specifically
around
eventing
right
here
at
the
top
of
main
there's
these
two
there's,
these
two
events
that
we
are
going
to
be
receiving
in
this
linux
world
that
we're
going
to
run
in
the
first
is
that
sig
term
event,
which
we
are
going
to
receive
when
system
d
decides
to
close
us
down.
So
somebody
goes
into
the
console
and
says
service
request,
metrics
processor,
stop!
B
This
is
the
thing
that
we'll
get
so
that
we
have
an
opportunity
to
do
something
or
respond
or
clean
up
or
whatever
the
other
is
more
of
just.
You
know
for
completeness
in
case
somebody
had
run
us
from
like
the
console
directly
and
then
they
hit
you
know,
control
c
to
stop
the
process.
Here's
here's
another
chance
for
us
to
clean
up
now.
Our
code
doesn't
actually
do
all
that
much
with
these
kind
of
volatile
resources
that
we
need
to
clean
up.
So
we
really
just
want
to
know
that
these
things
happened.
A
A
A
B
B
Yeah,
so
we're
a
really
small
team
and
each
of
us
have
a
lot
of
things
on
our
shoulders,
so
we
prefer
those
those
sort
of
things,
and
so
this
code
is
largely
after
we
set
up.
Some
events
is
just
an
infinite
while
loop,
where
we're
running
through
things
and
we
slow
it
down,
we
say
hey,
we
only
actually
want
to
do
things
once
every
10
seconds
or
so,
and
then
we
go
off
and
we
do
each
of
our
tasks
now.
B
So
all
of
our
nodes
is
are
running
a
redis
cluster
and
redis
already
has
a
way
of
solving
who
is
in
charge.
Who
is
the
who
is
the
primary
of
their
cluster,
and
so
we
just
figure
out
with
a
little
helper
method.
This
are
we
this
instance
of
the
processor.
Are
we
also
running
on
the
redis
master
server
and,
if
we're
not,
then
we're
just
going
to
go
to
sleep?
We
are
the
hot
spare.
A
B
A
B
So
hopefully
this
becomes
a
problem
for
us
later
and
we
need
to
solve
it
right
now.
The
files
are
very
manageable.
The
traffic
that
comes
in
gets
written
to
one
of
three
servers
that
will
respond
to
the
request
and
the
files
are
rolled
every
minute,
so
we
really
are
only
trying
to
digest
a
third
of
the
last
minutes
data
because
of
of
that
distribution.
B
How
that
slow
comes
into
another
point
I
wanted
to
talk
about,
which
is
logging
and
instrumentation
all
throughout
this
code.
There's
lots
of
calls
to
our
logging
service
to
log
metrics
of
how
long
a
particular
thing
is
taking
how
many
documents
did
we
do?
How
many
files
did
we
do
all
of
that
data
gets
packaged
up
and
sent
to
our
own
elastic
search
stack
that
we've
built
up
so
that
we're
constantly
watching
this
thing
to
see
how
fast
is
it
going?
Are
we
at
a
critical
threshold?
Do
we
need
to
add
more
capacity?
B
So
the
program
itself,
you
know
you
go
through
it's
very
it's
very
verbose
code,
very
procedural
code.
It
does
this.
It
does
that
it
does
that
each
of
these
things
is
just
kind
of
encapsulated
in
its
own
service
so
that
it
can
be,
you
know,
run
or
tested
or
whatever
on
on
its
own
right,
and
we
don't
need
to
worry
about
it
here
from
the
console
applications
perspective.
B
This
application,
when
it
is,
is
published.
We
have
a
published
profile
for
this
that
I
need
to
zoom
in
on
again.
This
published
profile
targets,
the
linux
environment,
so
we're
looking
at
the
linux
runtime
and
we
publish
a
single
self-contained
file.
So
this
thing
all
comes
down
to
a
request:
metrics
dot,
processor,
one
file,
thing
that
is
about
80
megs
for
it's
it's
published,
but
it
makes
deploying
this
thing.
Super
easy
super
easy.
B
B
Man,
oh
it
was,
it
was
awful.
It
was
literally
awful
having
to
figure
sidestepping
the
need
to
figure
out
what
version
of
what
framework
needs
to
deploy
to
what
server
is
is
amazing.
I
am
so
glad
that
this
exists.
If
anything,
I
would
say
this
is
the
killer
feature
right
here
I
mean
people
might
think
that
that's
silly,
but
like
this,
this
is
the
whole.
B
A
Yeah
for
those
developers
I
haven't
lived
in
the
days
of
the
big
enterprises,
where
you
know
the
framework
was
managed
tightly
by
iit
pro,
so
you
had
to
beg
for
the
right
version.
Man
I
mean
being
a
developer.
These
days
is
so
much
easier,
yeah,
but
yeah,
that's
fantastic.
I
love
how
you
know
easy.
It
is
to
even
with
this
one
right
everything
in
one
place.
You
run
the
exe
you're
done.
B
Yep,
and
so
once
we
have
that
that
executable-
and
we
put
it
out
into
our
linux
environment,
we
do
that
with
with
a
tool
chain
called
ansible,
which
is
like
a
yaml
based
tooling.
That
lets
us
basically
configure
what
our
servers
look
like
and
what
they
should
be
doing.
If
I
could
show
you
that
briefly,
I
know,
yaml
is
not
every
developer's
favorite
thing,
but
this
is
is
really
the
magic
incantation
for
what
this
is
that
creates
on
our
linux
servers
that
are
going
to
be
running
this
thing.
B
B
The
reason
why
we
have
to
run
it
as
root
has
to
do
with
that
single
packaging
thing,
so
the
downside
to
it
all
being
packed
into
one
file
is
that
internally,
when
we
go
off
and
run
this,
the
runtime
wants
to
unzip
the
contents
of
it
and
it
wants
to
unzip
the
contents
of
it
into
a
temp
directory,
a
temp
directory
owned
by
root,
and
we
can't
seem
to
get
around
that
thing.
We
can't
seem
to
find
the
right
incantation
of
permissions
to
do
that.
B
A
B
Great
so
all
of
this
comes
together
and
once
we
have
our
data
and
it's
it's
being
pulled
in
from
the
processor
and
stored
in
redis,
we
have
another.net
application,
which
we'll
talk
about
another
time,
which
is
an
asp.net
and
it
produces
a
cool
ui
of
all
of
that
performance
data
that
we
pulled
in.
So
we've
been
running
this
for
a
while
on
some
of
our
own
properties
like
we
run
this
on
trackjs.com,
and
so
we
can
look
at
how
does
our
own
site
perform
and
chart
chart
those
performance
characteristics?
B
So
here's
here's
like
an
example
report
based
on
that
data,
where
I
can
say
you
know,
over
the
last
45
days
or
or
last
48
hours,
I'm
sorry,
here's
how
fast
our
page
has
performed
our
average
page
has
performed
and
here's
how
fast
an
average
endpoint
has
performed.
You
know
two
and
a
half
seconds
or
200
milliseconds
and
I
can
go,
and
I
can
break
this
down
by
individual
things.
So
I
can
look
at
you
know
the
homepage
of
trackjs.com.
B
How
has
that
performed?
This
is
a
flame
chart,
so
you
can
see
like
how
many
people
experienced
it
at
what
different
kind
of
performance,
so
down
here
blues
are,
are
really
good.
There
were
four
people
who
had
less
than
a
quarter
of
a
second
low
time
and
they
had
you
know
a
really
great
time,
but
you
know
a
few
people.
Two
people
had
a
greater
than
10
second
load
time
and
they
had
a
really
bad
experience
and
so
understanding
that
distribution
for
each
site
is
really
interesting.
B
A
Great
well,
I
thought
I
have
to
say
thank
you
very
much
for
coming
and
telling
us
all
the
exciting
stuff
that
you
are
building
thanks
for
giving
us
some
good
insights
on
the
gotchas,
and
you
know
things
that
people
need
to
be
aware
of
as
they
develop
stuff.
And
we
look
forward
to
seeing
the
finished
product.